Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3733222imm; Thu, 17 May 2018 13:49:30 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqioy+DPSy7vjO1ytq16OU6yY4ENrbLLIaIpfCJ6+u+ahC4ZB9luVoBrvW7CaJGywhgXqxY X-Received: by 2002:a17:902:1744:: with SMTP id i62-v6mr6672166pli.267.1526590170735; Thu, 17 May 2018 13:49:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526590170; cv=none; d=google.com; s=arc-20160816; b=vd3+v1x9GEbdC21rYhtOF3cGeyypnHSRkkl3w6jZKeAOdtyvu0EkMs837Nw37gVTu2 W964fKbhhpLru5BOkLb8CEFbOttZPxRSc4We3DwHXpvROSXAgwsQl8/1t+/apNfFdfoW fMTHs35lgAU2Cuiu5ezowU9PACos5fM3EETOnNwY34VN8NCKWXr9FpU0bJDZy103Uftd EXneRVzPiFRxE3cihfRq7Jr2mlH3U00TeRFXoSue7x8msquP9laHZfDXIwfCoPlqkaxv A97pJLKjArMSYRtkkHFm2RfGRh4H/2XwSINqRgiEd6wsXzuQUmP3CjSHwQa0SZzTsavG NgSA== 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=TAh1hAYXpXqsEoA3O8GTiMJQZ/SsdTNM8w9pTsdqvOw=; b=cU+GWvhVoEEZZwxtrbrjH4A21Yo3QhPUmthKc4GY3wz9D4/zv8CgoUDE1P427y/Dbr 0a+MKVbHtSJR4Ey/qCry5rkAZaI1P1CoHHRnFvPNNXQ45Y3KIdTyScAaTEqmcqjzr9vS 9NIT40qz+oq7QW6Pz+lDVrOCcmAACBO5AIuOAcA4VH879iOsTaQII0L2mo80UaaqQPCR a+wzFQVw+04gpyyPRSVRkJyfBfls/lhC/DdYGSW8nZfrbdSnsfDGiewO76KLbXsQReZz V076cTtP7Th+FVv4j6geUP4b5Q58UO34Al5SB0jnWt238zDL1Dewd2WRVkigPKG2G5Hr /3Wg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=nWDfFXVW; dkim=pass header.i=@codeaurora.org header.s=default header.b=AUoCgADd; 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 z3-v6si5687091plb.228.2018.05.17.13.49.16; Thu, 17 May 2018 13:49:30 -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=nWDfFXVW; dkim=pass header.i=@codeaurora.org header.s=default header.b=AUoCgADd; 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 S1752320AbeEQUsq (ORCPT + 99 others); Thu, 17 May 2018 16:48:46 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:54666 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752002AbeEQUso (ORCPT ); Thu, 17 May 2018 16:48:44 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id C4AE760F61; Thu, 17 May 2018 20:48:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526590123; bh=Fd3kdyNVk3Sm4EQGngMVF9hs5msaxa5SNBCGxIDwnys=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nWDfFXVWxQD/SnVCKxH/dz2SK4F01+nvp8FjgRgFgphiGElrKXajOe89FATjY8gow z15PmDbk98odHNNPxWT14MgHZ7g5zTNXR+xugz0iQ4h3Eg5B9YVxlirs9m9z9F7HrT J/4r3xwjn4rf0TN0fTQszxjD4jc/gpKcNtHnltKk= 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.160.165] (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 7160E609D1; Thu, 17 May 2018 20:48:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526590122; bh=Fd3kdyNVk3Sm4EQGngMVF9hs5msaxa5SNBCGxIDwnys=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AUoCgADdHc2ci5Rdzz1hNU0KJ+eq8iAPLiSDsLoFAX4TrKGKFP9hjIS9fe1UBJdVN 4+pffUTKVdeNbwKcbCfY3QiPfu+Wwb8rDzCNIJZN6hl97/QG9IU1nxCAnEGPswT0Xe 4mw50LTu3Taxaofjrtve+sAZlelxBySuo5NzZYhA= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 7160E609D1 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> <20180517060948.GI20254@sirena.org.uk> From: David Collins Message-ID: <6cb2ac52-258c-332b-e912-809d16e14114@codeaurora.org> Date: Thu, 17 May 2018 13:48:41 -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: <20180517060948.GI20254@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 05/16/2018 11:09 PM, Mark Brown wrote: > On Tue, Apr 24, 2018 at 01:46:21PM -0700, David Collins wrote: >> 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. > > So the hardware implementation is some hard coding stuff that doesn't > really adequately reflect reality? This seems unfortunate. However do > we really need to tell the hardware about the fact that we're adding > extra headroom - are there actual interactions with non-Linux things > here? The RPMh hardware is configured by the boot loader. The configuration does reflect reality; however, it cannot handle all configurations at initialization time. Specific headroom management typically comes up in modem usecases for RF supplies that are sensitive to noise. This feature allows RPMh masters (application processor, modem processor, etc) to make requests only for the regulators that they directly care about without having to worry about power grid parent-child details and setting the voltage of parent regulators in order to ensure sufficient headroom. If you really don't like having this feature present in the Linux RPMh regulator driver, then I'd be ok removing it. It is not required for SDM845 which the driver is initially targeting. >>>> 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). > > Is the kernel somehow prevented from varying these voltages? Yes. Physically, there exists no RPMh register to read or write the voltage of LDOs managed via XOB. Additionally, the kernel running on the application processor is blocked from configuring the voltage via a direct SPMI writes by access permissions that crash the system when violated. Take care, David -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project