linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laxman Dewangan <ldewangan@nvidia.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: <robh+dt@kernel.org>, <pawel.moll@arm.com>,
	<mark.rutland@arm.com>, <ijc+devicetree@hellion.org.uk>,
	<galak@codeaurora.org>, <linus.walleij@linaro.org>,
	<gnurou@gmail.com>, <broonie@kernel.org>, <a.zummo@towertech.it>,
	<alexandre.belloni@free-electrons.com>, <lgirdwood@gmail.com>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-gpio@vger.kernel.org>, <rtc-linux@googlegroups.com>,
	<swarren@nvidia.com>, <treding@nvidia.com>,
	<k.kozlowski@samsung.com>, <vreddytalla@nvidia.com>
Subject: Re: [PATCH V7 1/8] mfd: add device-tree binding doc for PMIC max77620/max20024
Date: Wed, 10 Feb 2016 19:18:41 +0530	[thread overview]
Message-ID: <56BB3FB9.7050102@nvidia.com> (raw)
In-Reply-To: <20160210132333.GG24522@x1>


On Wednesday 10 February 2016 06:53 PM, Lee Jones wrote:
> On Tue, 09 Feb 2016, Laxman Dewangan wrote:
>
>> On Tuesday 09 February 2016 09:12 PM, Lee Jones wrote:
>>> On Sat, 30 Jan 2016, Laxman Dewangan wrote:
>>>
>>> +	Normal mode also called as active mode on which all step-down
>>> +		regulators, all linear regulators, GPIOs, and the 32kHz
>>> +		oscillator are in normal active mode.
>>> +	sleep mode: Regulators/GPIOs/clock can go on OFF state based on
>>> "can go on OFF state"?
>> Regulator/GPIO has two states, enable and disable. If sleep mode is
>> configured for these resource and external signal triggers to sleep
>> then this get disabled.
> It's the English that I'm unhappy with.
>
> "can go on OFF state" doesn't sound right.
>
>>>> +			source gets the control signal for ON and OFF.
>>>> +	Power on slot: 	Slot number on which resource is ON once FPS source
>>>> +			get ON signal.
>>> Can you find another way of explaining this please?
>> Hmm..
>> Does it look fine:
>> There is 8 slots for each FPS on which resource can get enabled.
>> This property provides the slot number on which resource gets
>> enabled after FPS sequence started.
> It's a bit better, yes.  Although it's still a little difficult to
> read.  In fact, I can't even recommend a suitable alternative, since I
> still do not understand exactly what it is you're trying to say.

I am sorry if I am not able to make it clear. Better I post the 
datasheet content so that it is easy to understand and then we can have 
better text here.


The Flexible Power Sequencer (FPS) allows each regulator to power up 
under hardware or software control. Additionally, each regulator can 
power on independently or among a group of other regulators with an 
adjustable power-up and power-down delays (sequencing). GPIO1, GPIO2, 
and GPIO3 can be programmed to be part of a sequence allowing external 
regulators to be sequenced along with internal regulators. nRST_IO can 
be programmed to be part of a sequence.

The flexible sequencing structure consists of two hardware enable inputs 
(EN0, EN1), and 3 master sequencing timers. Each master sequencing timer 
is programmable through its configuration register to have a hardware 
enable source or a software enable source (CNFGFPSx). When 
enabled/disabled the master sequencing timer generates eight sequencing 
events. The time period between each event is programmable within the 
configuration register.

Each regulator, GPIO1, GPIO2, GPIO3, and nRST_IO has a flexible power 
sequence slave register (FPS_x) which allows its enable source to be 
specified as a flexible power sequencer timer or a software bit. When a 
FPSSRCx specifies the enable source to be a flexible power sequencer, 
the power up and power down delays are configured by FPSPUx[2:0] and 
FPSPDx[2:0].can be specified in that regulators flexible power sequencer 
configuration register.



>>> +
>>> +-maxim,enable-sleep: 		    Boolean, enable sleep state of PMIC
>>> We already have bindings for sleeping.  Please use a generic one.
>> Which property? Saw sleep property with vendor prefix.
> I guess there are too many '.*sleep.*' properties now, each with
> slightly different syntax and meaning.  The situation is exacerbated
> by one of the key examples is using the property with cells expected
> i.e. non-bool.


My grep shows some sleep property and followig are near to which I am 
looking.

st,supports-sleepmode

pinctrl/ste,nomadik.txt:- ste,sleep: <0/1>
                                     0: sleep mode disable,
                                     1: sleep mode enable.


Should I made this as generic like

sleep: <0/1>
             0: sleep mode disable,
             1: sleep mode enable.

  reply	other threads:[~2016-02-10 14:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-30 16:38 [PATCH V7 0/8] Add support for MAXIM MAX77620/MAX20024 PMIC Laxman Dewangan
2016-01-30 16:38 ` [PATCH V7 1/8] mfd: add device-tree binding doc for PMIC max77620/max20024 Laxman Dewangan
2016-02-09 15:42   ` Lee Jones
2016-02-09 17:56     ` Laxman Dewangan
2016-02-10 13:23       ` Lee Jones
2016-02-10 13:48         ` Laxman Dewangan [this message]
2016-02-11  9:26           ` Lee Jones
2016-02-11 10:19             ` Laxman Dewangan
2016-01-30 16:38 ` [PATCH V7 2/8] mfd: max77620: add core driver for MAX77620/MAX20024 Laxman Dewangan
2016-01-30 17:16   ` kbuild test robot
2016-01-30 17:12     ` Laxman Dewangan
2016-02-01  8:25       ` Lee Jones
2016-02-01  8:31         ` Laxman Dewangan
2016-02-01  9:02           ` Lee Jones
2016-02-01  9:15             ` Laxman Dewangan
2016-01-30 17:52   ` kbuild test robot
2016-01-30 16:38 ` [PATCH V7 3/8] pinctrl: add DT binding doc for pincontrol of PMIC max77620/max20024 Laxman Dewangan
2016-02-05 14:48   ` Linus Walleij
2016-01-30 16:38 ` [PATCH V7 4/8] pinctrl: max77620: add pincontrol driver for MAX77620/MAX20024 Laxman Dewangan
2016-01-30 16:38 ` [PATCH V7 5/8] gpio: add DT binding doc for gpio of PMIC max77620/max20024 Laxman Dewangan
2016-02-05 14:48   ` [rtc-linux] " Linus Walleij
2016-02-09 14:29     ` Lee Jones
2016-01-30 16:38 ` [PATCH V7 6/8] gpio: max77620: add gpio driver for MAX77620/MAX20024 Laxman Dewangan
2016-01-30 16:38 ` [PATCH V7 7/8] regulator: add DT binding doc for regulator of PMIC max77620/max20024 Laxman Dewangan
2016-01-30 16:38 ` [PATCH V7 8/8] regulator: max77620: add regulator driver for max77620/max20024 Laxman Dewangan
2016-02-09 15:02   ` Laxman Dewangan
2016-02-09 15:36     ` Mark Brown

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=56BB3FB9.7050102@nvidia.com \
    --to=ldewangan@nvidia.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=gnurou@gmail.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=k.kozlowski@samsung.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=rtc-linux@googlegroups.com \
    --cc=swarren@nvidia.com \
    --cc=treding@nvidia.com \
    --cc=vreddytalla@nvidia.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;
as well as URLs for NNTP newsgroup(s).