From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 523A5C282CB for ; Fri, 8 Feb 2019 09:08:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1F3BB2147C for ; Fri, 8 Feb 2019 09:08:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="lFYYvhO1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727457AbfBHJI2 (ORCPT ); Fri, 8 Feb 2019 04:08:28 -0500 Received: from mail-pg1-f194.google.com ([209.85.215.194]:45142 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727269AbfBHJI2 (ORCPT ); Fri, 8 Feb 2019 04:08:28 -0500 Received: by mail-pg1-f194.google.com with SMTP id y4so1297624pgc.12 for ; Fri, 08 Feb 2019 01:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ksdMWoE6UjyCJLnY5OFwn+SGFvDycxlsnIlwQ1W31+s=; b=lFYYvhO1ckSkJqK1nnJTyo3DDuGFQhSWRYNck+c+A8SXemeO7NMSrZPTqJT0puZ7yl sWs5L4RwTJ4QYTm2Ec2HeK4G0jFOrvh+Pc790lFSe4NYFAbhD/UhzGmD7jycWPluC8oS UVzKhQ8vfztof6QGHVi+sYeCeI//zmzCYsyBD1fDLEsuClxMqyfvw0RytuFf5azwBNAW IhD1ffVgkGRggBCsu7XdkW1DXClYVuYu3Ip0x5AVPFhP/ftygPxhoCKtDSO9P2ZPTZIM WmG0Lu79foQtnL9dQ12rcvdQlbGnkfnDEVC+LVl3p9zLAjfc6OlqyW+/stJ1dkvwaaku mlyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ksdMWoE6UjyCJLnY5OFwn+SGFvDycxlsnIlwQ1W31+s=; b=BMbRkg+EGyCCZ8b0VpUBPYVgDGgWC6r4fZm4yhpyADG/RDF89VIPwGoGtJWr5GdMeG S6BqvpkNAWdfgnIssRCcv030PxiOmQJoJJ7ke0PEzPQ873WGkmT/XQJjfNBta+U0Z6Hk rBsxrtdmGWqugNk1HjS2W5nHRjObKeOdDn9Aq7hHcdMKJ14Xq8fm27+dl8AzTnKHfFN7 NWeAlbbPSDfa1OGt3GrMmEyBXfGnwmsdRt8ELwMSrsY7wOwmqV6RW9EewSD0QYav5x2K j8QgynwXwfiUYzNk/cbetv+mds/6gu6vFmwHCzVStoAVyrA4BXE6GPzwzokMriYXR7iX oslQ== X-Gm-Message-State: AHQUAuaRsFG07OTLl1XypdgcRVcb7pwRv0Bqcn0B6I4Ho4k+93SQcVT9 QJXMWpTQ0wOMr0gMD9tLAaST6Q== X-Google-Smtp-Source: AHgI3IYCVhGBDI2L+ANfCSyr4qXTKVs6cO+aBJHjwbSS0QTXp0g67p0cc5sYCLMOfi/Uyfnr/rpKBw== X-Received: by 2002:a63:4e15:: with SMTP id c21mr9694048pgb.50.1549616907463; Fri, 08 Feb 2019 01:08:27 -0800 (PST) Received: from localhost ([122.172.102.63]) by smtp.gmail.com with ESMTPSA id e9sm6230112pfh.42.2019.02.08.01.08.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 01:08:26 -0800 (PST) Date: Fri, 8 Feb 2019 14:38:24 +0530 From: Viresh Kumar To: Juri Lelli Cc: "Rafael J. Wysocki" , Rafael Wysocki , Greg Kroah-Hartman , Viresh Kumar , Linux PM , Vincent Guittot , Matthias Kaehlcke , Linux Kernel Mailing List Subject: Re: [PATCH 0/3] drivers: Frequency constraint infrastructure Message-ID: <20190208090824.4dxtux4vcltkq7go@vireshk-i7> References: <20190117131631.GA14385@localhost.localdomain> <20190130052511.5k6mhwu45vzpz6il@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190130052511.5k6mhwu45vzpz6il@vireshk-i7> User-Agent: NeoMutt/20180323-120-3dd1ac Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30-01-19, 10:55, Viresh Kumar wrote: > On 17-01-19, 14:16, Juri Lelli wrote: > > I was also wondering how this new framework is dealing with > > constraints/request imposed/generated by the scheduler and related > > interfaces (thinking about schedutil and Patrick's util_clamp). > > I am not very sure about what constraints are imposed by schedutil or > util-clamp stuff that may not work well with this stuff. > > As you are already aware of it, this series isn't doing anything new > as we already have thermal/user constraints available in kernel. I am > just trying to implement a better way to present those to the cpufreq > core. @Juri: Ping. -- viresh