Received: by 10.192.165.148 with SMTP id m20csp38280imm; Tue, 24 Apr 2018 16:43:38 -0700 (PDT) X-Google-Smtp-Source: AIpwx49SIqJQUIYnLfeZhbp/KCuaOOliDFSP2cv23JuXrD1+zYEKdpLKe1XLpjjml44prKMjW1D9 X-Received: by 2002:a17:902:6c07:: with SMTP id q7-v6mr27195029plk.67.1524613418582; Tue, 24 Apr 2018 16:43:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524613418; cv=none; d=google.com; s=arc-20160816; b=SHrRWX7HRjXo7qSvxsTYdHfg1Z+quT01ezdWuQsawUzmcs8Alq6sBXQrtkeLkYzxAN DwIE4DUKdqu1GJa5fFMcZgUWBEZddK0w+CEaeTjoVG1h1WrdxDjTypN3qNHGqJa8ASXF IilRMVsxlNZ7wI7kjoPBuOqH3qBDW1P6plJM14aJVy/HRAJDte4IfTRhbxMSOlsvi1V0 +vw8GMLVB5P3VFoeKFFjmo89Al6rMy1WZcTbhRetHx15nQ2uCHsxmXZ+XGS3AtyO1hrI ipyuQxPrmHTlheqy2DnK4DfvWkV9A1TwSCtGTTb96Udzz00zyXoCuIC6vvLQlWaUbEJa y6hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to:date :arc-authentication-results; bh=Pt73TvmGfi3Fj5LN89OMlGHaLUkFoCo/qfanK8drmjI=; b=Q6gc0xXXMKDAhNdX2qqEnVMdLHkC8mo82kSFnNsHXgiffWV2GLJOA0J0jB5bXeAgxW X+sZEg1mwuSzc4byxUGyOUgDkCSYOQqBseakWcxD8WE+WLqDJUBe6Go2Ac68y6l0yGBM 4UhZgOhBI2ErwZcPEL96/JcmWgNG1+Ri/9VeHvQv+PwklbXWEpuB6uQ7MbCvegaCo85Y cVStFxiKoOQIZYcucF5xu7445vUH+jI5HTirNsB9PUXfdjEDu6T1G+Ybn4TOB4avKk4c 9iHsItJ1gSADQS7/hRVKN4JLB11qMKiWHj3xUYY42NCYiLZj3w7YgG+/vjdE+ITCsxvt i73A== ARC-Authentication-Results: i=1; mx.google.com; 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 o12si12061384pgv.367.2018.04.24.16.43.23; Tue, 24 Apr 2018 16:43:38 -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; 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 S1751233AbeDXXmH convert rfc822-to-8bit (ORCPT + 99 others); Tue, 24 Apr 2018 19:42:07 -0400 Received: from hermes.aosc.io ([199.195.250.187]:45738 "EHLO hermes.aosc.io" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbeDXXmF (ORCPT ); Tue, 24 Apr 2018 19:42:05 -0400 Received: from localhost (localhost [127.0.0.1]) (Authenticated sender: icenowy@aosc.io) by hermes.aosc.io (Postfix) with ESMTPSA id 421CB5B2A4; Tue, 24 Apr 2018 23:41:58 +0000 (UTC) Date: Wed, 25 Apr 2018 07:41:35 +0800 In-Reply-To: <20180424170733.GD22073@sirena.org.uk> References: <20180423144657.63264-1-icenowy@aosc.io> <20180423144657.63264-3-icenowy@aosc.io> <20180424170733.GD22073@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH v3 2/3] regulator: add support for SY8106A regulator To: linux-arm-kernel@lists.infradead.org, Mark Brown CC: Ondrej Jirman , devicetree@vger.kernel.org, Maxime Ripard , linux-sunxi@googlegroups.com, Liam Girdwood , linux-kernel@vger.kernel.org, Chen-Yu Tsai , Rob Herring From: Icenowy Zheng Message-ID: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 于 2018年4月25日 GMT+08:00 上午1:07:33, Mark Brown 写到: >On Mon, Apr 23, 2018 at 10:46:56PM +0800, Icenowy Zheng wrote: > >> --- /dev/null >> +++ b/drivers/regulator/sy8106a-regulator.c >> @@ -0,0 +1,176 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * sy8106a-regulator.c - Regulator device driver for SY8106A > >Just make the entire thing a C++ comment so it looks consistent and >joined up. SPDX identifier is special -- it should be in a seperated comment block. > >> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, >unsigned int sel) >> +{ >> + /* We use our set_voltage_sel in order to avoid unnecessary I2C >> + * chatter, because the regulator_get_voltage_sel_regmap using >> + * apply_bit would perform 4 unnecessary transfers instead of one, >> + * increasing the chance of error. >> + */ >> + return regmap_write(rdev->regmap, rdev->desc->vsel_reg, >> + sel | SY8106A_GO_BIT); > >Why would it do these extra transfers? Is this just the fact that you >didn't set up a register cache (though the r/m/w cycle should only add >the read)? We could put some logic in the core regmap code to detect >that an _update_bits() call is going to write to the whole register, >though it'd be even easier to just let this register be cached. > >Generally if we can usefully optimize things we should do it at the >framework level. Oh maybe the comment needs to be changed, but it's needed to enable it to change voltage, as it might be not enabled at boot. > >> + if (reg & SY8106A_GO_BIT) >> + return reg & rdev->desc->vsel_mask; >> + else >> + return (chip->fixed_voltage - rdev->desc->min_uV) / >> + rdev->desc->uV_step; > >You could use the standard get_voltage_sel() if you provide a mapping >operation that set everything with _GO_BIT set to return the fixed >voltage. Though looking at this it seems that the fixed voltage will >always be one that could be set via the register anyway so I'm >wondering >if the easiest thing here isn't to just have the driver turn off >_GO_BIT Do you mean "turn on" here? >during probe() and not worry about the special case at runtime.