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 V4 1/5] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024
Date: Wed, 27 Jan 2016 07:24:30 +0000 [thread overview]
Message-ID: <20160127072430.GD3368@x1> (raw)
In-Reply-To: <56A79DB4.6090000@nvidia.com>
On Tue, 26 Jan 2016, Laxman Dewangan wrote:
>
> On Tuesday 26 January 2016 08:28 PM, Lee Jones wrote:
> >On Mon, 25 Jan 2016, Laxman Dewangan wrote:
> >
> >>Hmm. I describe the boolean and tristate only. Do I need to define
> >>type for integer,string also?
> >I wouldn't describe any of them. It's normally pretty obvious which
> >properties are boolean by the lack of required cell description.
> >
>
> Rob suggested to use the type also for Boolean and tristate. I think
> it is good to have for all places that what type of values are
> valid.
It's fine, and some people do describe them. I've just never seen the
point, especially if you have a nice example of their use in the
document. But if you insist, please ensure you are consistent, so
*all* bools need to be described. That is not currently the case.
> >>>>+The property for fps child nodes as:
> >>>>+Required properties:
> >>>>+ -reg: FPS number like 0, 1, 2 for FPS0, FPS1 and FPS2 respectively.
> >>>I'm surprised Rob Acked this. We don't usually do device numbers in DT.
> >>What is best way to make the child node for FPS and differentiate FPS0,1, 2?
> >>What is your suggestion here?
> >There are lots of ways you can solve this and so many examples of
> >others doing so. I suggest you have a look at some DTS files and
> >figure it out. One possible solution is to use different compatible
> >strings.
> Here, I think I can go similar to regulators where child node name
> identifies the regulators.
>
> fps-config {
> fps0 {
> maxim,fps-time-period-us = <1280>;
> maxim,fps-enable-input = <FPS_EN_SRC_EN0>;
> };
>
> fps1 {
> maxim,fps-time-period-us = <2560>;
> maxim,fps-enable-input = <FPS_EN_SRC_EN1>;
> };
>
> fps2 {
> maxim,fps-time-period-us = <640>;
> maxim,fps-enable-input = <FPS_EN_SRC_SW>;
> };
> };
>
> So node name gives the FPS name.
That is also an acceptable means to solve the issue.
As I said, there are many ways to skin a cat.
> >>>+Pinmux and GPIO:
> >>>+===============
> >>>I think this whole section needs moving to ../pinctrl and needs to be
> >>>reviewed by Linus W.
> >>Is this mean I need to create DT binding doc for the each subsystem
> >>differently?
> >>Actually during AS3722, I had different understanding to have single file.
> >Yes, that way you have each of the the subsystem experts review your
> >documentation. You can then link to them from this document.
> OK, I will add different dt binding doc in respective driver and
> squash that with respected submodule drivers.
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-01-27 7:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-19 10:19 [PATCH V4 0/5] Add support for MAXIM MAX77620/MAX20024 PMIC Laxman Dewangan
2016-01-19 10:19 ` [PATCH V4 1/5] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024 Laxman Dewangan
2016-01-25 11:56 ` Lee Jones
2016-01-25 15:08 ` Laxman Dewangan
2016-01-26 14:58 ` Lee Jones
2016-01-26 16:24 ` Laxman Dewangan
2016-01-27 7:24 ` Lee Jones [this message]
2016-01-19 10:19 ` [PATCH V4 2/5] mfd: max77620: add core driver for MAX77620/MAX20024 Laxman Dewangan
2016-01-20 5:22 ` Krzysztof Kozlowski
2016-01-22 11:39 ` Laxman Dewangan
[not found] ` <56A214EB.30905-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-01-25 11:29 ` Lee Jones
2016-01-25 11:20 ` Laxman Dewangan
2016-01-19 10:19 ` [PATCH V4 3/5] pinctrl: max77620: add pincontrol " Laxman Dewangan
2016-01-28 10:04 ` Linus Walleij
2016-01-28 10:13 ` Laxman Dewangan
2016-01-19 10:19 ` [PATCH V4 4/5] gpio: max77620: add gpio " Laxman Dewangan
[not found] ` <1453198783-28383-5-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-01-28 10:05 ` Linus Walleij
2016-01-19 10:19 ` [PATCH V4 5/5] regulator: max77620: add regulator driver for max77620/max20024 Laxman Dewangan
2016-01-20 5:25 ` Krzysztof Kozlowski
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=20160127072430.GD3368@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 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).