public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Flora Fu <flora.fu@mediatek.com>
To: Mark Brown <broonie@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-kernel@vger.kernel.org, Lee Jones <lee.jones@linaro.org>,
	Russell King <linux@arm.linux.org.uk>,
	Samuel Ortiz <sameo@linux.intel.com>,
	Sandeep Nair <sandeep_n@ti.com>,
	Grant Likely <grant.likely@linaro.org>,
	"Joe.C" <yingjoe.chen@mediatek.com>,
	Thierry Reding <treding@nvidia.com>,
	devicetree@vger.kernel.org,
	Vladimir Murzin <vladimir.murzin@arm.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Rob Herring <robh+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Stephen Warren <swarren@nvidia.com>,
	Eddie Huang <eddie.huang@mediatek.com>,
	linux-arm-kernel@lists.infradead.org,
	Dongdong Cheng <dongdong.cheng@mediatek.com>,
	srv_heupstream@mediatek.comPeter De Schrijver <p>
Subject: Re: [PATCH v2 3/8] regulator: MT6397: Add support for MT6397 regulator
Date: Mon, 1 Dec 2014 10:51:44 +0800	[thread overview]
Message-ID: <1417402305.30873.78.camel@mtksdaap41> (raw)
In-Reply-To: <20141128152247.GR7712@sirena.org.uk>

Hi, Mark

On Fri, 2014-11-28 at 15:22 +0000, Mark Brown wrote:
> On Fri, Nov 28, 2014 at 11:54:29AM +0800, Flora Fu wrote:
> 
> > @@ -96,5 +97,4 @@ obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
> >  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
> >  obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
> >  
> > -
> >  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
> 
> Random whitespace change here...
> 
> > +	/* For HW design, buck voltage control register has two parts.
> > +	 * part 1: vsel_reg for register mode
> > +	 * part 2: voselon_reg or hw control mode
> > +	 * Both parts should be updated and sync when user set voltage.
> > +	 */
> 
> Why does nothing else in the driver know about this "hw control mode" -
> what does it actually mean, shouldn't it affect some of the other
> operations?

In the regulator, we have two parts of registers to control the output
in voltage selection. The mode setting is done in boot loader stage
before kernel.
The hw control mode is used for external signal to control voltage
selection. When the hw control mode is chosen, "voselon" register is the
action register to do voltage selection if consumer make voltage
selection. Without hw control mode, vsel_reg is the action register.
To fit all mode selection, we update and sync two parts of registers in
regulator framework.

> 
> > +static int mt6397_buck_get_voltage_sel(struct regulator_dev *rdev)
> > +{
> 
> > +static int mt6397_regulator_is_enabled(struct regulator_dev *rdev)
> > +{
> 
> To repeat my comments on the last version: please use the generic regmap
> operations rather than copying them.
> 

The generic helper function does not fit usage of the regulator. 
In general function, it considers that the vsel_reg for selection
voltage is also the register for querying voltage selection. The enable
bit for enable function is the bit for querying the status. 

In the hardware design, the output of voltage selection register is
different from vsel_reg. Is is located in nivosel. The enable bit is
locate in the other bit called "qi_mask".  
Please check comment in MT6397 regulators' information. 
/*
 * MT6397 regulators' information
 *
 * @desc: standard fields of regulator description.
 * @voselon_reg: Register sections for hardware control mode of bucks
 * @nivosel_reg: Register for query output voltage selection of bucks
 * @qi_mask: Mask for query enable signal status of regulators
 */
struct mt6397_regulator_info {
	struct regulator_desc desc;
	u32 voselon_reg;
	u32 nivosel_reg;
	u32 qi_mask;
};

That's whey ops ".get_voltage_sel" and ".is_enabled" is not able to use
generic regamp.


> > +	np = of_node_get(pdev->dev.parent->of_node);
> > +	if (!np)
> > +		return -EINVAL;
> > +
> > +	regulators = of_get_child_by_name(np, "regulators");
> 
> To further repeat my

>  previous review comments:
> 
> | Define regulators_node and of_match in the regulator desc and you can
> | remove both this table and all your DT matching code in the driver, the
> | core will handle it for you.
> 
> Please don't ignore review comments.

Sure, I think I completely misunderstood what you meant. Could you give
more details about the comments?
In this version, the table for DT matching is removed and merged into
regulator info in table mt6397_regulators. To register every regulator
by devm_regulator_register(), the of_node is parsed from
of_regulator_match() by name. Here is to retrieves the device_node
"regulators" for of_regulator_match() to get all regulator_init_data and
corresponding of_node.
Is any other mechanism I can use to achieve these part without
of_regulstor_match()?


Thanks,
Flora

  reply	other threads:[~2014-12-01  2:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-28  3:54 [PATCH v2 0/8] Add Support for MediaTek PMIC MT6397 MFD Core and Regulator Flora Fu
2014-11-28  3:54 ` [PATCH v2 1/8] soc: mediatek: Add PMIC wrapper for MT8135 and MT6397 SoC Flora Fu
2014-11-28 15:32   ` Mark Brown
2014-11-28  3:54 ` [PATCH v2 2/8] mfd: MT6397: Add support for PMIC MT6397 MFD Flora Fu
2014-12-01 11:47   ` Lee Jones
2014-11-28  3:54 ` [PATCH v2 3/8] regulator: MT6397: Add support for MT6397 regulator Flora Fu
     [not found]   ` <1417146874-5232-4-git-send-email-flora.fu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2014-11-28 15:22     ` Mark Brown
2014-12-01  2:51       ` Flora Fu [this message]
2014-12-01 16:12         ` Mark Brown
2014-11-28  3:54 ` [PATCH v2 4/8] dt-bindings:: Add document for MT8135 PMIC Wrapper Flora Fu
2014-11-28  3:54 ` [PATCH v2 5/8] dt-bindings: Add document for MT6397 MFD Flora Fu
2014-11-28  3:54 ` [PATCH v2 6/8] dt-bindings: Add document for MT6397 regulator Flora Fu
     [not found]   ` <1417146874-5232-7-git-send-email-flora.fu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2014-11-28 15:30     ` Mark Brown
2014-11-28  3:54 ` [PATCH v2 7/8] ARM: dts: mt8135: Add support for PMIC MT6397 MFD Flora Fu
2014-11-28  3:54 ` [PATCH v2 8/8] ARM: dts: mt8135: Add support for MT6397 regulator Flora Fu
2014-11-28 15:30   ` Mark Brown
2014-12-01  3:19     ` Flora Fu
2014-12-01  6:40       ` Sascha Hauer
2014-12-01 11:16       ` Mark Brown
     [not found] ` <1417146874-5232-1-git-send-email-flora.fu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2014-12-01  7:04   ` [PATCH v2 0/8] Add Support for MediaTek PMIC MT6397 MFD Core and Regulator Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1417402305.30873.78.camel@mtksdaap41 \
    --to=flora.fu@mediatek.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dongdong.cheng@mediatek.com \
    --cc=eddie.huang@mediatek.com \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=sandeep_n@ti.com \
    --cc=srv_heupstream@mediatek.comPeter \
    --cc=swarren@nvidia.com \
    --cc=treding@nvidia.com \
    --cc=vladimir.murzin@arm.com \
    --cc=yingjoe.chen@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox