Received: by 10.192.165.148 with SMTP id m20csp5101736imm; Tue, 24 Apr 2018 13:48:02 -0700 (PDT) X-Google-Smtp-Source: AIpwx49qRNoBv2v+znNpOr7V8Ofehitk52XeAiZkUpo1ER4j3Gft8vVz7YgsIzb/W8/pgHOsDjpM X-Received: by 10.99.0.200 with SMTP id 191mr21455605pga.33.1524602882393; Tue, 24 Apr 2018 13:48:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524602882; cv=none; d=google.com; s=arc-20160816; b=in/cxgnnYPPFQ56jDs9UQ2xcTdGQvj8AaI3y0fxMdIoy9qDHXPzi+USy7z0av2Idaj IJAKGui+tU4Fea+7KNnrNufIyPfVQ955Sss3ztXPfpTa4e2qBYo/0RvayBAB+TdKc77C uwKVUBPCUCViaImtwDKze9mobztIgyirgHqqy/8J2yigde4t9v84Uf0CeV1qYL558d3Y 64p1nN5z1PFkIUEJV4loh5lW3VcMcdU8Al3foUBQzfY46F7vy0dHr1TOGtNdXChIAkdr UDfj1brp0OXu/PSmIII6du2O5/O0nN3Qf6KD+6JZSPYzgmFIkw2ssXxiPhVpL/OntM6S eecA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=/M5Exub+Y0yCKSw/ZJZMAEO+Pr0M1JS9zG2pultyTTk=; b=TXYS5PE0Ke3z0/3PGNy3QzVPn8YYfc0vvciRbbxVKKQY5JwbT0+N8HTYuOADS7QHCo 7iCbbde5eg5M1k+hdulrx6MVMc2bXcEwjrxNF8UVk6AdxeqUwCE6E+R0y/CK/1CXBmWr YD24XOoR0jCo0xxKLY5vVRQ7h7ZRd2QHKk26JD6j8bPBGU7csxorkp+V08hXWC4WWK5w L4t5+78+SMtF3BEK79l8ngICKDBd4g2Lh4H13WC8W+OgN+UxaTex2z1cn822wHRqgNp+ rNO1uusu4h1siEOviOfJr/ZTjzHj2U93TK07JX1E40XK47k6JWmWpQIPr+DBpW0J6wq3 TY2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=I/Z2fpg0; dkim=pass header.i=@codeaurora.org header.s=default header.b=I/Z2fpg0; 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 f191si12053693pgc.660.2018.04.24.13.47.47; Tue, 24 Apr 2018 13:48:02 -0700 (PDT) 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=I/Z2fpg0; dkim=pass header.i=@codeaurora.org header.s=default header.b=I/Z2fpg0; 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 S1751690AbeDXUq1 (ORCPT + 99 others); Tue, 24 Apr 2018 16:46:27 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:59170 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbeDXUqY (ORCPT ); Tue, 24 Apr 2018 16:46:24 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id E245960A06; Tue, 24 Apr 2018 20:46:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1524602783; bh=4yQEq3jItujlLjvisNI2x3rFk978O/jpHuIhTRbbB0s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=I/Z2fpg0mAJ/Ss5E/PKdaraSQa20TqomGFHACw/nCs8BLmtINIOXoJkGWR5vudYCD gh7aNVQjPdsVaprJh1lZ6MDMk4kEWOJ3+THrn7WNbQxpcY58lbzs2mZqvGzgAFc/DB F0gxyTRAXbLvpCfCEHSNsx42Y7S945BoUX0BM3y4= 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 [10.46.164.143] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: collinsd@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 193DB6071A; Tue, 24 Apr 2018 20:46:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1524602783; bh=4yQEq3jItujlLjvisNI2x3rFk978O/jpHuIhTRbbB0s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=I/Z2fpg0mAJ/Ss5E/PKdaraSQa20TqomGFHACw/nCs8BLmtINIOXoJkGWR5vudYCD gh7aNVQjPdsVaprJh1lZ6MDMk4kEWOJ3+THrn7WNbQxpcY58lbzs2mZqvGzgAFc/DB F0gxyTRAXbLvpCfCEHSNsx42Y7S945BoUX0BM3y4= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 193DB6071A 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=collinsd@codeaurora.org Subject: Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver To: Mark Brown Cc: Stephen Boyd , lgirdwood@gmail.com, mark.rutland@arm.com, robh+dt@kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, rnayak@codeaurora.org, ilina@codeaurora.org References: <71fab82672524b95632cdb588c16edfc9711866a.1521246069.git.collinsd@codeaurora.org> <152165924074.91116.13025068669916027026@swboyd.mtv.corp.google.com> <493c1f5d-df99-ca68-0f90-a7937a696f5d@codeaurora.org> <152411734938.46528.9676451637772936597@swboyd.mtv.corp.google.com> <20180419120813.GD27188@sirena.org.uk> <38f42537-f801-115a-4120-1344a67a0462@codeaurora.org> <20180424174111.GH22073@sirena.org.uk> From: David Collins Message-ID: Date: Tue, 24 Apr 2018 13:46:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20180424174111.GH22073@sirena.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/24/2018 10:41 AM, Mark Brown wrote: > On Fri, Apr 20, 2018 at 12:28:21PM -0700, David Collins wrote: >> RPMh hardware enforces the requested minimum headroom voltage for all >> regulators with a parent. It has full knowledge of the parent-child >> connections of regulators on the board (as programmed by the bootloader). >> It automatically reconfigures the parent voltage when needed as a result >> of requests changing the voltage of any of its child regulators. > > If the hardware has full knowledge of all these constraints and enforces > them transparently then why does the kernel care that it's doing that? > Doesn't it defeat the point of it doing all this stuff if we have to > know about it? The RPMh hardware is aware of the parent-child connections between regulators as well as minimum headroom to ensure stable LDO voltage output for subregulated LDOs. The intention of having the headroom be a configurable property for processors is to support usecases in which subregulated LDO loads are particularly sensitive to noise and require additional headroom. Such usecases are board dependent and beyond the baseline configurations set in RPMh hardware. >>> Ideally future versions of the RPM will have improved interfaces, >>> there's a bunch of problems like this :( > >> Do you have a preference for qcom,regulator-initial-microvolt vs a generic >> framework supported regulator-initial-microvolt property for configuring a >> specific voltage at registration time? We'll need to have support for one >> or the other in order for the qcom_rpmh-regulator driver to be functional. > > This is basically specific to Qualcomm, I can't off hand think of any > other devices with similar issues. I will go with qcom,regulator-initial-microvolt then. >>> Yes, constraints that specify a single voltage are done by setting min >>> and max to the same value. fixed_uV is *only* for regulators that have >>> a physically fixed voltage. > >> XOB managed regulators physically cannot change voltage. Therefore, do >> you agree that it is reasonable to use fixed_uV for them? Note that I >> removed init_data->constraints.apply_uV manipulation in version 2 of this >> patch. > > If these regulators can't change voltage then surely we know what > voltage they have without needing it to be specified in DT? In the case of XOB managed LDO regulators, the LDOs physically can be configured to different voltages by the bootloader. However, the RPMh interface provides no mechanism for the application processor to read or change that voltage. Therefore, we need a way to specify such voltages in a board specific (as opposed to driver specific) manner (i.e. device tree). Take care, David -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project