Received: by 10.213.65.68 with SMTP id h4csp1054083imn; Tue, 27 Mar 2018 13:53:44 -0700 (PDT) X-Google-Smtp-Source: AIpwx490US++nCpeQRaVm9yM/lI56B0AMHXbZLBWCFX30FcL0dYlI8GShU3ebVV8UMrP5NoRW/lu X-Received: by 2002:a17:902:744b:: with SMTP id e11-v6mr799261plt.351.1522184024459; Tue, 27 Mar 2018 13:53:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522184024; cv=none; d=google.com; s=arc-20160816; b=bF7pWc7PJqgVbT3HvAuLZaNmfQDaWWtU1MdKlYWtBXAHW3SrmO6gmuGoXJInYvLjK+ 5YMdweUkddA89wjpf1Ce9CmFhRUcFRsw1jFrhEskFIRl4SnVSYAHGE2IvbLboZXvAWVh MCPJ8qOqFBPblGZgwizAqMcC2Ndy13G0in8+fe3SOkqTKerSbQ0/M5Y+DVotZWlcY4T5 8dvro4TBkqHdnvHvYmYTDIjZfInwMrNKeBcRx2BKtckT4mNm3o1jk1IduCozKQDUmTyu UzM3inlPhKVXqvU4s2binr6UHsMAkKLjRKRx1DreJcDg4taTy8nlyGxXmpuJb32nisOQ iHsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=ZqcORE3kGNkQApYbCvM5Bi4YuoCRvh+vlArOQuSnTDA=; b=GfWcl7NMXFl5kBCcxLNAHuYroSVK63qihC59ARrjvn4FFDgYy+bJ0Q2apy+AeVkJLZ afMBMc8o52nJEdIxSCnIpcMWIBQ5CFORoNsvCa7M4uQvpRpy8dsTk4IzutlmGS9e36+4 GewAph9zUVEN1gORTKxdbYa1Fq+pSs0qoKXBfny0MSELua3eh9c0N0CSmbj5tNMj5DKR r+Yy65ZMv+gDsmmJM0VpOgz8aarsdQJiG8B49VQJjKuHGEX/spfJaRArRr5h7/Uu90mg KG2g/FflRJCr1XVAKbLgihYWdWkP7nLXaDQB4tkWm6jg6to8k4x9N/w/8zA8ONp5yuyf FkVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=baGXU+aS; dkim=fail header.i=@chromium.org header.s=google header.b=F6ESfp/w; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k7si1376384pgo.509.2018.03.27.13.53.29; Tue, 27 Mar 2018 13:53:44 -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=fail header.i=@google.com header.s=20161025 header.b=baGXU+aS; dkim=fail header.i=@chromium.org header.s=google header.b=F6ESfp/w; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751937AbeC0UwB (ORCPT + 99 others); Tue, 27 Mar 2018 16:52:01 -0400 Received: from mail-ua0-f177.google.com ([209.85.217.177]:42597 "EHLO mail-ua0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751020AbeC0Uv6 (ORCPT ); Tue, 27 Mar 2018 16:51:58 -0400 Received: by mail-ua0-f177.google.com with SMTP id o34so171238uae.9 for ; Tue, 27 Mar 2018 13:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZqcORE3kGNkQApYbCvM5Bi4YuoCRvh+vlArOQuSnTDA=; b=baGXU+aSWJfxG9J69S+GO62zy9mjU9fWEonAK4BcahcRbzSQVpKF8InbJMKREbQrXS 2Ew/lWHZhkD1Ia4XOkDlDRSy4vkeG2WB9WSZhDkcNR/NMDbgRNIDb9YmZwbPP1LSsPIj yacx5Bvp9S/shoiEet/B0eVI/s1Tpm/N67/GOOl6bHixZtagGIUbeIpr9i2h/8/iSSoy rQpLQuu+jVJmlG0M44005o5NZjwBJGm1rGYGA5bK7556IUyU1V7nrjbaPzuN3zCnMcSe 9ZuS89EGmUo2UNrByD5+UtjZ4K6Ra0H4khCnFbxAVjpooZgE1ewcRDSXiqeBiSEH8GuO gSaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZqcORE3kGNkQApYbCvM5Bi4YuoCRvh+vlArOQuSnTDA=; b=F6ESfp/w3VjHnPd1bQ1UFscSj8IR0CL396NWJ2WgZeiQeX2RIj7oUtiDybIX0ftNZj bnG9ZB6wlVGdmjgJHU/3q30cR8KEFfBmol5c7pZX7/1a859yH+95zsMqe99IRVGUjnWo aN76b5+wfDWMLPhKziyACLZ5MDCvQ1MnILE48= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZqcORE3kGNkQApYbCvM5Bi4YuoCRvh+vlArOQuSnTDA=; b=p2ZeJ3tpE4POnOxZqdhrWZ75ByrYxVOmUER1aUUziCEsca9krJ/y/UJKL6NKpwORi5 Uo0VJeIeWzQUUMIRdtcDiakcoB+fcSGA1TLX/Ypl0U5/u/bvmjX+4ZITZVu9Zwno1JYR 0tp63yWvfy8Po2k8sMj4ZfuXhMo/CnLWA8mteQBNEwwbFUtv4ZWULMd2jsNr1zahSzJ0 EUvEGG83dQNXyViuktBLCFPED6JF23bCgPdyMk9Mh6nWVh/kEjplo+Llzxrib7ojpgjq SPgiwcpq8g8n9y7yQJIOqnwogWODC8WfDUN6h+9mmQSpzOdyAG7yT1LMYwgyTYYFbKFd HudA== X-Gm-Message-State: AElRT7EAjeoxs4uhqljL6yaDn8TTAX3A++frAIxiu7F0/aK6XSkMnrir bVCfizRetWeTYZuRHj7TulD4kiWmrl9yhA5V20vwVw== X-Received: by 10.176.92.33 with SMTP id q33mr725860uaf.108.1522183917561; Tue, 27 Mar 2018 13:51:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.4.8 with HTTP; Tue, 27 Mar 2018 13:51:56 -0700 (PDT) In-Reply-To: <20180327115606.GC29239@sirena.org.uk> References: <71fab82672524b95632cdb588c16edfc9711866a.1521246069.git.collinsd@codeaurora.org> <184378e4-caf8-6ce3-e089-3690588fcb28@codeaurora.org> <20180327115606.GC29239@sirena.org.uk> From: Doug Anderson Date: Tue, 27 Mar 2018 13:51:56 -0700 X-Google-Sender-Auth: Eh0-Thhm5GGEnuCFS2CUxAGa8eU Message-ID: Subject: Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver To: Mark Brown Cc: David Collins , Liam Girdwood , Rob Herring , Mark Rutland , linux-arm-msm@vger.kernel.org, Linux ARM , devicetree@vger.kernel.org, LKML , Rajendra Nayak , sboyd@kernel.org, ilina@codeaurora.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Mar 27, 2018 at 4:56 AM, Mark Brown wrote: >> > Here is an explanation for why the "device tree mode" abstraction is >> > present in the first place. Between different Qualcomm Technologies, Inc. >> > PMICs, regulators support a subset of the same modes (HPM/PWM, AUTO, >> > LPM/PFM, Retention, and pass-through). However, the register values for >> > the same modes vary between different regulator types and different PMIC >> > families. This patch is adding support for several PMIC4 family PMICs. >> > The values needed for to-be-released PMIC5 PMIC regulators are different. >> > As an example, here are the different values for LPM/PFM across PMIC >> > families and regulator types: PMIC4 LDO/SMPS = 5, PMIC4 BOB = 1, PMIC5 >> > LDO/HFSMPS/BOB = 4, PMIC5 FTSMPS = N/A. Having the "device tree mode" >> > ensures that it is not possible to inadvertently specify a PMIC specific >> > mode in device tree which corresponds to the wrong type or family but >> > which aliases a value that would be accepted as correct. > >> I'm OK with having the "device tree mode" abstraction, and in fact the >> current regulator framework seems to want you to have this anyway. If >> I read the code correctly, you're required to have the conversion >> function and there's no default. > > I didn't spot this in the code but something called "device tree mode" > sounds like it's going to be awfully confusing... Just to clarify this bit: The regulator framework allows for a callback function of_map_mode() in regulator drivers. My reading of the code shows that if you wish to use the property "regulator-initial-mode" (like this regulator does) that it is _required_ to provide an of_map_mode() function. Assuming I didn't mess up my analysis, the entire job of of_map_mode() is to convert from one integer to another. It should take the number that was specified in the device tree and convert it to a REGULATOR_MODE_XXX. That means that the regulator framework is enforcing a distinct and per-regulator numbering system for the mode (I called this "device tree mode"). Just for kicks, right now these are the REGULATOR_MODEs: #define REGULATOR_MODE_FAST 0x1 #define REGULATOR_MODE_NORMAL 0x2 #define REGULATOR_MODE_IDLE 0x4 #define REGULATOR_MODE_STANDBY 0x8 -- In cpcap_map_mode(): 0 (CPCAP_BIT_AUDIO_NORMAL_MODE) => 0x2 (normal) 0x40 (CPCAP_BIT_AUDIO_LOW_PWR) ==> 0x8 (standby) else => error -- In max77802_map_mode(): 3 (MAX77802_OPMODE_NORMAL) ==> 0x2 (normal) else (intends 1 or MAX77802_OPMODE_LP) ==> 0x8 (standby) -- In spmi_regulator_of_map_mode(): 1 => 0x2 (normal) 2 => 0x1 (fast) else => 0x4 (idle) -- In twl4030reg_map_mode(): 0xe (RES_STATE_ACTIVE) => 0x2 (normal) 0x8 (RES_STATE_SLEEP) => 0x8 (standby) else => error -- So basically it sounds like everyone makes up some arbitrary numbering system that is only used in their device tree files and needs to be mapped into the standard numbering system... Perhaps the right answer is to improve the regulator core to make of_map_mode() optional? We'd have to figure out where to place the #defines for the default of_map_mode() so they could be used in .dts files, but that should be possible. Presumably it would be wise to add a new property that was a bitmask of valid modes... -Doug