From: Lee Jones <lee.jones@linaro.org>
To: Laxman Dewangan <ldewangan@nvidia.com>
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: Thu, 11 Feb 2016 09:26:04 +0000 [thread overview]
Message-ID: <20160211092604.GG3782@x1> (raw)
In-Reply-To: <56BB3FB9.7050102@nvidia.com>
On Wed, 10 Feb 2016, Laxman Dewangan wrote:
>
> 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.
Perfect, let's go with that.
> >>>+-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.
Ideally yes. This is obviously going to be used again.
However;
- My fear is that it will get confused with the 'sleep' property in
Documentation/devicetree/booting-without-of.txt.
- Secondly, you would need to get Rob to Ack it.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Laxman Dewangan <ldewangan@nvidia.com>
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: [rtc-linux] Re: [PATCH V7 1/8] mfd: add device-tree binding doc for PMIC max77620/max20024
Date: Thu, 11 Feb 2016 09:26:04 +0000 [thread overview]
Message-ID: <20160211092604.GG3782@x1> (raw)
In-Reply-To: <56BB3FB9.7050102@nvidia.com>
On Wed, 10 Feb 2016, Laxman Dewangan wrote:
>=20
> 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.
>=20
> 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.
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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.
Perfect, let's go with that.
> >>>+-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.
>=20
>=20
> My grep shows some sleep property and followig are near to which I
> am looking.
>=20
> st,supports-sleepmode
>=20
> pinctrl/ste,nomadik.txt:- ste,sleep: <0/1>
> 0: sleep mode disable,
> 1: sleep mode enable.
>=20
>=20
> Should I made this as generic like
>=20
> sleep: <0/1>
> 0: sleep mode disable,
> 1: sleep mode enable.
Ideally yes. This is obviously going to be used again.
However;
- My fear is that it will get confused with the 'sleep' property in
Documentation/devicetree/booting-without-of.txt.
- Secondly, you would need to get Rob to Ack it.
--=20
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org =E2=94=82 Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--=20
--=20
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---=20
You received this message because you are subscribed to the Google Groups "=
rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
next prev parent reply other threads:[~2016-02-11 9:26 UTC|newest]
Thread overview: 75+ 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 ` Laxman Dewangan
2016-01-30 16:38 ` [rtc-linux] " Laxman Dewangan
2016-01-30 16:38 ` [PATCH V7 1/8] mfd: add device-tree binding doc for PMIC max77620/max20024 Laxman Dewangan
2016-01-30 16:38 ` Laxman Dewangan
2016-01-30 16:38 ` [rtc-linux] " Laxman Dewangan
2016-02-09 15:42 ` Lee Jones
2016-02-09 15:42 ` Lee Jones
2016-02-09 15:42 ` [rtc-linux] " Lee Jones
2016-02-09 17:56 ` Laxman Dewangan
2016-02-09 17:56 ` Laxman Dewangan
2016-02-09 17:56 ` [rtc-linux] " Laxman Dewangan
2016-02-10 13:23 ` Lee Jones
2016-02-10 13:23 ` [rtc-linux] " Lee Jones
2016-02-10 13:48 ` Laxman Dewangan
2016-02-10 13:48 ` Laxman Dewangan
2016-02-10 13:48 ` [rtc-linux] " Laxman Dewangan
2016-02-11 9:26 ` Lee Jones [this message]
2016-02-11 9:26 ` Lee Jones
2016-02-11 10:19 ` Laxman Dewangan
2016-02-11 10:19 ` Laxman Dewangan
2016-02-11 10:19 ` [rtc-linux] " Laxman Dewangan
2016-01-30 16:38 ` [PATCH V7 2/8] mfd: max77620: add core driver for MAX77620/MAX20024 Laxman Dewangan
2016-01-30 16:38 ` Laxman Dewangan
2016-01-30 16:38 ` [rtc-linux] " Laxman Dewangan
[not found] ` <1454171931-27752-3-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-01-30 17:16 ` kbuild test robot
2016-01-30 17:16 ` kbuild test robot
2016-01-30 17:16 ` [rtc-linux] " kbuild test robot
2016-01-30 17:12 ` Laxman Dewangan
2016-01-30 17:12 ` Laxman Dewangan
2016-01-30 17:12 ` [rtc-linux] " Laxman Dewangan
2016-02-01 8:25 ` Lee Jones
2016-02-01 8:25 ` Lee Jones
2016-02-01 8:25 ` [rtc-linux] " Lee Jones
2016-02-01 8:31 ` Laxman Dewangan
2016-02-01 8:31 ` Laxman Dewangan
2016-02-01 8:31 ` [rtc-linux] " Laxman Dewangan
2016-02-01 9:02 ` Lee Jones
2016-02-01 9:02 ` [rtc-linux] " Lee Jones
2016-02-01 9:15 ` Laxman Dewangan
2016-02-01 9:15 ` Laxman Dewangan
2016-02-01 9:15 ` [rtc-linux] " Laxman Dewangan
2016-01-30 17:52 ` kbuild test robot
2016-01-30 17:52 ` kbuild test robot
2016-01-30 17:52 ` [rtc-linux] " 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-01-30 16:38 ` Laxman Dewangan
2016-01-30 16:38 ` [rtc-linux] " Laxman Dewangan
2016-02-05 14:48 ` Linus Walleij
2016-02-05 14:48 ` [rtc-linux] " 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 ` Laxman Dewangan
2016-01-30 16:38 ` [rtc-linux] " 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-01-30 16:38 ` Laxman Dewangan
2016-01-30 16:38 ` [rtc-linux] " Laxman Dewangan
2016-02-05 14:48 ` Linus Walleij
2016-02-05 14:48 ` Linus Walleij
2016-02-09 14:29 ` Lee Jones
2016-02-09 14:29 ` Lee Jones
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 ` Laxman Dewangan
2016-01-30 16:38 ` [rtc-linux] " 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 ` Laxman Dewangan
2016-01-30 16:38 ` [rtc-linux] " Laxman Dewangan
2016-01-30 16:38 ` [PATCH V7 8/8] regulator: max77620: add regulator driver for max77620/max20024 Laxman Dewangan
2016-01-30 16:38 ` Laxman Dewangan
2016-01-30 16:38 ` [rtc-linux] " Laxman Dewangan
2016-02-09 15:02 ` Laxman Dewangan
2016-02-09 15:02 ` Laxman Dewangan
2016-02-09 15:02 ` [rtc-linux] " Laxman Dewangan
2016-02-09 15:36 ` Mark Brown
2016-02-09 15:36 ` [rtc-linux] " 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=20160211092604.GG3782@x1 \
--to=lee.jones@linaro.org \
--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=ldewangan@nvidia.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.