Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4446181imm; Wed, 30 May 2018 05:57:37 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJXM4hUrX9hme3/+FS3Vd96KKgPfqG1apLBFuieL+Q8u+knn2NkZ6SNFeGriPRUToak4xNB X-Received: by 2002:a63:7344:: with SMTP id d4-v6mr2111790pgn.273.1527685057218; Wed, 30 May 2018 05:57:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527685057; cv=none; d=google.com; s=arc-20160816; b=NZXhanBmWCSCeczYmfmxRMN4Tox9Yae5yDKetCLOxxjzrqy1wF/X3QCh3tWAat1tdB MXQUS2a/Zfp56RGLXa9xjLG2KKsGPhATOGAirsELWykURo9RnCEkKcjPiAWfgYElCoko mB6qGXKp41EozxYKy5rum5eFg3BB1uUDdEk9YF2/rm5ScCBG6laaW39s0nXDCV5qPp16 ux3G6i2fS14sii9RgQUbynIUhS2VLArmQ/P/I70PWbF0HvzbRikwMS5MaWWNJjSeFlcx 0zkAw51rjoE+T8BPItTEmVfA+x7xrisJqhV+RTpAri3TWF7eYrFoU7hTNCB7u35UedS4 B23w== 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:date:from:dkim-signature:arc-authentication-results; bh=8aIzk6kZaZDrXNmPVyOlzYcBRsE1e7jxjmpdLHcNF1s=; b=RBaV13PYLd/P2hhl2btmSmye04kqhjddl045+mlsPoXuHqQEbhuy08QU6kKwFLkUF8 4xrRIcTmoCW1wIi58+FdhCxpLae5b05VLrCmc1vNumI/KpFzjK97iFLvBFWlIcYM06ua okeBR+3Iyxi95muR4ztsyF/OdxSV+ZdbZ8aQnGGGS/9y8Q9wHfdOuxt+N1Lj3mabk/E6 mzzqHIX6fyBxNGdMfogVoFYXudM6qX9lwRA2TdIecJxuV+N80fdYW5ybJ9RDSYPj+MHH YT7bVWmnzHZa6I+JfgfdMHDoUXp/8undBVLDSC3xKseob6KNcK3xNTP3msQ61/BJewQx +Jhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=BdSs49y0; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a66-v6si36738754pfb.81.2018.05.30.05.57.23; Wed, 30 May 2018 05:57:37 -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=@gmail.com header.s=20161025 header.b=BdSs49y0; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753213AbeE3M4m (ORCPT + 99 others); Wed, 30 May 2018 08:56:42 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:42907 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751771AbeE3M4j (ORCPT ); Wed, 30 May 2018 08:56:39 -0400 Received: by mail-lf0-f67.google.com with SMTP id v135-v6so4129290lfa.9; Wed, 30 May 2018 05:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8aIzk6kZaZDrXNmPVyOlzYcBRsE1e7jxjmpdLHcNF1s=; b=BdSs49y00xow0z1jvJr+ztANP53pMkmGxhPee0zEXKLE6g9sOacz6aBIDeXyb/OTIY tHOvahJ5ggMLzOSzFerFc/zFatAkg/0nG2/WcUn6jr89TdGQsQTTuQ2U1rwaFaN1Rn9x 1X2INFVqcKK0o+cxQ2YJCsEhysN6zfNrCtkODB+XUw6z1pWNoxYRVygGpi9JLo/QgNew 3cAU1BRfEM1ed+zFpeXunJanTzhmc+8ULTO31gcECYAnjLaeGc+CTWj/laAHHzc74hST PRsY+a/T9Po0CCOVGaMin0oRDCsRMj1QaSOtXmOjGIn5LJg0e07rlQ9gQ3nb26jPdTk+ 0+GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8aIzk6kZaZDrXNmPVyOlzYcBRsE1e7jxjmpdLHcNF1s=; b=EiiA+UHA0CZyokIUGLbWmDfGofvSTC4ofEA834Dtx7VGbQlYMdrGB5fOF+7dklQAUs gbL/dJXfUkOSNzR986qKtfsW8l6SoUhSw8t4Dh2aHvTcAzsFmSn5yQ1pRdW92FzFYzv8 ElfZmDDQJJy2szwbQkctK98VOvgG6dw1EIHga7/Y/+2e66NXTlo2Wrd8Bn2U1hqpDT3n Cz9A1PgIrFFWrLpTwQT3j8u36Xd+74I3FHVH6bXXn1f32JF4loxsS8a/svu8/7oOHOuv CzvbP/2kIt9w/xbpzK76A+q0vjF/KPWfHafXcDWcCw7qwjGr1mEQeAxssdFpcy0onj9i oH1w== X-Gm-Message-State: ALKqPwd3ap4PMonl2S7dPGv4oK4ddm2thpq1RXjGEX3SjmJg3hkp+G0Z CE0Uh7Atq/zYUS0k33UPQFU= X-Received: by 2002:a2e:9d41:: with SMTP id y1-v6mr2044647ljj.112.1527684997352; Wed, 30 May 2018 05:56:37 -0700 (PDT) Received: from localhost.localdomain ([213.255.186.34]) by smtp.gmail.com with ESMTPSA id z4-v6sm7089926lji.14.2018.05.30.05.56.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 30 May 2018 05:56:36 -0700 (PDT) From: Matti Vaittinen X-Google-Original-From: Matti Vaittinen Date: Wed, 30 May 2018 15:56:34 +0300 To: Mark Brown Cc: Matti Vaittinen , Matti Vaittinen , mturquette@baylibre.com, sboyd@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, lee.jones@linaro.org, lgirdwood@gmail.com, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, mikko.mutanen@fi.rohmeurope.com, heikki.haikola@fi.rohmeurope.com Subject: Re: [PATCH v4 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver Message-ID: <20180530125634.GE13528@localhost.localdomain> References: <20180530090512.GC13528@localhost.localdomain> <20180530110000.GI6920@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180530110000.GI6920@sirena.org.uk> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 30, 2018 at 12:00:00PM +0100, Mark Brown wrote: > On Wed, May 30, 2018 at 12:05:12PM +0300, Matti Vaittinen wrote: > > > Other 4 can be used on PWM or PFM switching mode. When PWM is used > > voltages can be changed without disabling regulator. On PFM this should > > not be done. These latter 4 regulators can be forced to PWM mode via > > control bit in register. This driver does not support controlling this > > mode though. So this driver version just checks if regulator is enabled > > before changing the voltage and if it is the voltage change fails with > > -EBUSY > > It probably should support setting modes (especially if the device isn't > smart enough to automatically shift which sounds like the case) but > that's a separate thing. Thanks for the guidance! The first 4 BUCKs (which support DVS) do change the mode automatically. Latter 4 do not. I however didn't find example on how to allow doing this mode change via regulator framework and thus the driver is not allowing mode change. For me it would sound good to allow setting the mode via device-tree property - and via in-kernel API or sysfs - but as I said I didn't yet find a nice example on that. (But I assume this device is not first one allowing mode change and thus there should be an example and I probably should not invent own DT properties or sysfs entries for this. Guess I just need to search harder). > > > My question is whether it would be good idea to also read the 'force > > PWM' bit when voltage is changed and allow the change if PWM mode is > > forced to be used? Problem is that the check and voltage change can't be > > atomic so there is a chance someone changes the mode (bypassing the > > driver and regulator core) after this check but before we get to modify > > the voltage. Furthermore, I doubt the 'force PWM' is widely used (but I > > can't say for sure as I can't imagine all use cases) as it is not so > > power efficient. > > Why would anything else be changing the mode configuration of the > regulator while the system is running? That sounds like a bad idea. This was also my initial thought. Still with my lack of experience on this area (and with my experience on people inventing strange solutions) I felt unsure. > In any case if the hardware really needs to be manually put into force > PWM to change voltage then the simplest thing would be to just move it > into force PWM mode, do the change, then change back if it wasn't > already in force PWM mode. I see 4 options for these last 4 bucks which can't switch to PWM automatically when voltage is changed. 1. prohibit voltage change if regulator is enabled (safest? current approach) 2. allow voltage change if regulator is enabled and force PWM is used 3. switch to 'force PWM' when changing voltage (as suggested by Mark) 4. disable regulator for duration of voltage change (discarded option) So option 4 was discarded. Option 1 is the current approach. I will ask from ROHM PMIC HW colleagues what they think of Mark's suggestion (option 3) and implement it if HW behaves Ok. I guess option 2 is not worth the hassle. > > The tradeoff with forced PWM mode is that the quality of regulation will > be a lot better, especially if the load changes suddenly (as things like > CPUs often do). Most hardware that's at all current is able respond to > changes in load and switch modes automatically when it's appropriate, > except possibly in some very low power modes. Yes. The mode switching is automatic. But there is this control bit for disabling automatic mode switching and forcing the PWM. Problem with these 4 last bucks is just that if regulator is in PFM (and it may be if not forced to PWM - due to this automatic switching) then the voltage change is not behaving well. Thanks for all the support Mark! Br, Matti Vaittinen