Received: by 10.223.164.202 with SMTP id h10csp52098wrb; Wed, 29 Nov 2017 16:52:15 -0800 (PST) X-Google-Smtp-Source: AGs4zMbd3ibvdMPBRzKo6c/jCCm7wfQ7bRXSxtCqphuIm1hSGCSNh7Q8j9kPosDAOtLBvsudXkaP X-Received: by 10.84.246.20 with SMTP id k20mr722419pll.209.1512003135074; Wed, 29 Nov 2017 16:52:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512003135; cv=none; d=google.com; s=arc-20160816; b=GYRM3nBiznK9D5AOZmJo4MGFOijJGzS5wvcmd4sgpJMak3Wr0bMQ7PNTZaWDbaRqp5 +qZ2ZzQ6YkxxdTU30HHLjGe6oYPh+5jAmwQYKNmU8jDBBkJYLGsaJ7qN4K0GbkpH3/GE 51CfsKjADC8iJZU671+JhTtyvjSWOpugcDJEjrU5YR2pmW7NP0cklk0W6GzbzKIKIxxo zCagwoHN2XTtKrD4pahgXJBYEwnNafAy/KQacsB891sSY/rFXdZAOMO1bO1qomyTR8F/ O2QOFA1RcdxoPaOkIgnYwsQhgikDkGxq66Th9u+URy7khcRxcSjLKqwIOnmms/yKGYyb b3/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:dkim-signature:dkim-signature :arc-authentication-results; bh=l7ODjjQYW9V5pkQh33hpIOLmL82SpuqgopoqM/WZ6WI=; b=g7RYSems5XHgr4fmO/nc2I8NggAUYepFkRj+UD9rsTtE5IB7Y1qapjoa7MRxRycz8U yoFjGILHDPX3BghKD6K0JFntxW17L11CvrQaWYD8EkVeu4e+aPZotusNl8f2fXRQJvJ1 JVUcnpIj12h2hXTsgGkF97Q3VcmyiA0E8AJVL4IjVEtZ7oULmJkcEAZEZCQi2nZeZka5 r0twvAGIYcw5uCDE/O3YcWR0e6o2ixJgBQzqhOOXIOVEMXKTdwNLGPo+PJ4icinbplv+ OLvjtZKTmAD6B6BL+86CGa3+tHCBrXviuCWyolBWwbD9e6qJy95LihJuyZE5SRbQ0ZLt 7g/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=aGx6kCEt; dkim=pass header.i=@codeaurora.org header.s=default header.b=dm/U0W9o; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c7si2157638pll.411.2017.11.29.16.52.01; Wed, 29 Nov 2017 16:52:15 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=aGx6kCEt; dkim=pass header.i=@codeaurora.org header.s=default header.b=dm/U0W9o; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753758AbdK3Aue (ORCPT + 99 others); Wed, 29 Nov 2017 19:50:34 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:50378 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753596AbdK3Auc (ORCPT ); Wed, 29 Nov 2017 19:50:32 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id B55CD6072C; Thu, 30 Nov 2017 00:50:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1512003031; bh=OhWSoFMGSfUrMH2MGIGblwQ9EBvh7wbGp+wJH8I2svQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aGx6kCEtXiW0hvonLIUvokVD/2rjCs4WNXa39lcqg57XlOMRKl/Z3tGTQIshP7scI qNbiBkoneYLioiJPWa3dpIWDbqpQz/ZXQ9O/H03Shvim0+6HZbkdtxKKz6camslBQx eYSlkdunkYNXud80FeTK5WCcY7XD4SDHFEpWHv0k= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from localhost (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sboyd@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 1F4486034F; Thu, 30 Nov 2017 00:50:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1512003030; bh=OhWSoFMGSfUrMH2MGIGblwQ9EBvh7wbGp+wJH8I2svQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dm/U0W9o7L60m4S1nP2VOjT2HEPKlh80tV+9nf5uJh2HPgg42nWe/64hWkLJ2FGwn 3aeg9t3v8//3aqNRevDAVa1zGONEs9V+jBVyTkHECftkGFRMo3RHWIC3loZ23ObvUG YrK8LA+JtPg7DHqApTa5D+o1RVzqu7iJ1BCj7/3g= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 1F4486034F Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sboyd@codeaurora.org Date: Wed, 29 Nov 2017 16:50:29 -0800 From: Stephen Boyd To: Ulf Hansson Cc: Viresh Kumar , Rob Herring , Kevin Hilman , Viresh Kumar , Nishanth Menon , Rafael Wysocki , "linux-pm@vger.kernel.org" , Vincent Guittot , Rajendra Nayak , Sudeep Holla , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values Message-ID: <20171130005029.GC19419@codeaurora.org> References: <23ba51eaa6b52117458165dccc00a95cf8e86e1d.1509453284.git.viresh.kumar@linaro.org> <20171101214333.GG30645@codeaurora.org> <20171102045155.GX4240@vireshk-i7> <20171102071533.GM30645@codeaurora.org> <20171102090033.GZ4240@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/28, Ulf Hansson wrote: > On 2 November 2017 at 10:00, Viresh Kumar wrote: > > On 02-11-17, 00:15, Stephen Boyd wrote: > >> Sorry I'm not following. We're going to need to have platform > >> specific code that understands platform specific bindings that > >> aren't shoved into the generic OPP bindings. > > > > At least I am not targeting any platform specific binding right now. > > The way I see this to work is: > > > > - We will reuse earlier bindings and allow opp-hz and opp-microvolt to > > contain special values (this patch). > > - Platform specific DT entries will put corner numbers in opp-hz (or > > opp-microvolt) fields. > > - Some platform specific driver (in OPP or genpd) will be used to > > convert OPP into a performance state (corner) value. Now that can > > simply read opp-hz (or opp-microvolt) and return its value. > > Since the "operating-points-v2" phandle(s) belongs in the power-domain > controller device node, which anyway is being parsed by the genpd SoC > specific driver, I assume it makes sense to start the initialization > from there. Unless there is something that prevents that, of course. > > Then whatever library/helper functions we need for parse and create > the OPP tables, can be provided to the OPP framework and the OPP OF > library. > > > - OPP core will request for a performance state (code is already > > merged for that). > > > > And so there is no platform specific binding here. Do you want to do > > this differently ? > > This makes sense to me! > > Also, the SoC (QCOM) specific genpd driver is free to use the > terminology "corner values", when it translates opp-hz|microvolt into > such values. > Sorry it still makes zero sense to me. It seems that we're trying to make the OPP table parsing generic just for the sake of code brevity. Is this the goal? From a DT writer perspective it seems confusing to say that opp-microvolt is sometimes a microvolt and sometimes not a microvolt. Why can't the SoC specific genpd driver parse something like "qcom,corner" instead out of the node? BTW, I don't believe I have a use-case where I want to express power domain OPP tables. I have many devices that all have different frequencies that are all tied into the same power domain. This binding makes it look like we can only have one frequency per domain which won't work. I want to express that a device with a range of frequencies (or really multiple ranges of frequencies) is inside certain physical power domains and the frequency of the clks dictates the minimum voltage requirement of those power domains. For the most complicated case, imagine something like our eMMC controller that has two clks (clk1,clk2) that it changes the rate of independently and those two clks rely on two different regulators (vreg1, vreg2) that supply voltage domains in the SoC which the eMMC controller happens to be part of (pd1, pd2). And the device is also part of another power domain that we use to turn everything off (pd3). +-------+ +-------+ | vreg1 | | vreg2 | +---+---+ +----+--+ | | | +------------+-------------+ | | | +-------+ | +--------+ | | +-----> | clk1 | | | clk2 | <---------+ | +---+---+ | +----+---+ | | | | | | +----------v--------------v-----------+ | | | | | | | | | | | | pd1 | pd2 | | | | | | | | +------------+-------------+ | | | | pd3 eMMC | +-------------------------------------+ >From a DT perspective, I see this as one emmc node: pd: power-domain-controller { #power-domain-cells = <1>; }; cc: clock-controller { #clock-cells = <1>; }; emmc { power-domains = <&pd 1> <&pd 2>, <&pd 3>; clocks = <&cc 1> <&cc 2>; } And then we really don't want to have to express every single possible frequency that clk1 and clk2 can be just to express the voltage/corner constraints. It could be that we have some table like so: clk1 Hz | pd1 Corner ------------+----------- 40000 | 0 960000 | 0 19200000 | 1 25000000 | 1 50000000 | 2 74000000 | 3 clk2 Hz | pd2 Corner ------------+----------- 19200000 | 0 150000000 | 1 340000000 | 2 BUT we also have another device that uses pd1 and has it's own clk3 with different frequency constraints: clk3 Hz | pd1 Corner -------------+----------- 250000000 | 0 360000000 | 1 730000000 | 2 So when clk3 is at 730000000, we don't care what frequency clk1 is running at, pd1 needs to be at least at corner 2. If it's at corner 3 because clk1 is at 74000000 then that's fine. I imagine DT would look like our "fmax tables" that are currently out of tree. Something like: clk1_fmax_table { fmax0 { reg = /bits/ 64 <960000>; qcom,corner = <0>; }; fmax1 { reg = /bits/ 64 <25000000>; qcom,corner = <1>; }; fmax2 { reg = /bits/ 64 <50000000>; qcom,corner = <2>; }; fmax3 { reg = /bits/ 64 <740000000>; qcom,corner = <3>; }; }; Which is similar to OPP table, but we only list the maximum frequency that requires a particular corner. We're back to the same problem we have with OPPs of figuring out how to relate a table to a certain clk and power domain though. At least for qcom, we could do that with some sort of complicated list property: emmc { performance-states = <&fmax_table &cc 1 &pd 1> }; or something like that which would parse a table, a clock, and a number of power domains. Reminds me, we can have one clk frequency map to multiple power domains too. We have this case for our CPUs and PLLs where we have individual power control on two domains for one frequency. So when the PLL frequency changes, we need to turn on and set the voltage or corner of two regulators. So I don't really know how this is all going to work. I'd really appreciate to see the full picture though. Reviewing this a bit at a time makes me lose sight of the bigger picture. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From 1585328642576957290@xxx Tue Nov 28 16:40:09 +0000 2017 X-GM-THRID: 1582777408429643294 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread