From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "robh+dt@kernel.org" <robh+dt@kernel.org>
Cc: "broonie@kernel.org" <broonie@kernel.org>,
"dmurphy@ti.com" <dmurphy@ti.com>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
"mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
"mturquette@baylibre.com" <mturquette@baylibre.com>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"a.zummo@towertech.it" <a.zummo@towertech.it>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
"sboyd@kernel.org" <sboyd@kernel.org>,
"lee.jones@linaro.org" <lee.jones@linaro.org>,
"jacek.anaszewski@gmail.com" <jacek.anaszewski@gmail.com>,
"pavel@ucw.cz" <pavel@ucw.cz>
Subject: Re: [RFC PATCH 11/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC
Date: Tue, 29 Oct 2019 13:29:13 +0000 [thread overview]
Message-ID: <81291f685a52002352b68bfc3749e2ed09c03ca0.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <CAL_Jsq+_4SaVHqZFXhF_J+yqqcjuzEZpxFvxJfzsNpL1xBQijw@mail.gmail.com>
Hello Rob,
On Fri, 2019-10-25 at 10:47 -0500, Rob Herring wrote:
> On Fri, Oct 25, 2019 at 9:37 AM Vaittinen, Matti
> <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> > Hello Peeps,
> >
> > On Fri, 2019-10-25 at 08:24 -0500, Rob Herring wrote:
> > > On Fri, Oct 25, 2019 at 2:07 AM Vaittinen, Matti
> > > <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> > > The cases for not having child nodes are when you have child
> > > nodes
> > > with nothing more than a compatible and possibly provider
> > > properties
> > > (e.g. #gpio-cells for gpio providers). If you have other resource
> > > dependencies (e.g. clocks) or data to define (e.g. voltages for
> > > regulators), then child nodes absolutely make sense.
> >
> > Thanks for telling the reasoning behind. Makes sense.
> >
> > > Once we have
> > > child nodes, then generally it is easier for every function to be
> > > a
> > > child node and not mix the two. I'm sure I have told people
> > > incorrectly to not do child nodes because they define incomplete
> > > bindings.
> >
> > Does this mean that if I add LED controlled node with LED nodes
> > inside
> > - then I should actually add sub nodes for clk and GPIO too? I
> > would
> > prefer still having the clk provider information in MFD node as
> > adding
> > a sub-node for clk would probably require changes in the
> > bd718x7_clk
> > driver. (Not big ones but avoidable if clk provider information can
> > still dwell in MFD node).
>
> Probably not, if there's an existing structure to follow, then
> continue doing that.
Ok, thanks.
>
> > > I would group the led nodes under an led-controller node (with a
> > > compatible). The simple reason is each level only has one
> > > number/address space and you can't mix different ones. You're not
> > > numbering the leds here, but could you (with numbers that
> > > correspond
> > > to something in the h/w, not just 0..N)?
> >
> > I don't know what that would be. The LED controller resides in MFD
> > device in I2C bus and has no meaningful numbers I can think of. The
> > actual LEDs (on my board) are dummy devices and I really don't know
> > how
> > to invent meaningfull numbers for them either.
>
> If you have something like "led control registers 1, 2, 3" where
> 1,2,3
> is each LED channel, then use that.
Unfortunately, no. LED controls are in same register.
> Or if the LED supplies (or supply
> pins) have some numbering, use that.
I don't know how to format the numbering either. Currently planned PMIC
package is so called "UCSP55M3C" meaning the pins are in a matrix -
columns having numbers from 1 to 8 and rows having letters from A to J.
In this case the LED outputs are F6 and H6. I don't know if different
packaging is planned. Only 'constant' I can find is the output pin
naming 'GRNLED' and 'AMBLED' :/
> If there's none of that, then
> following standard node names kind of falls apart. '<generic name>-N'
> is what I've been defining for some schema.
So I could use node names led-1 and led-2 in the example, right?
Br,
Matti Vaittinen
next prev parent reply other threads:[~2019-10-29 13:29 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 9:40 [RFC PATCH 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
2019-10-17 9:41 ` [RFC PATCH 01/13] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
2019-10-17 9:42 ` [RFC PATCH 02/13] mfd: input: bd71828: Add power-key support Matti Vaittinen
2019-10-17 9:43 ` [RFC PATCH 03/13] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
2019-10-17 9:44 ` [RFC PATCH 04/13] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
2019-10-17 9:44 ` [RFC PATCH 05/13] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators Matti Vaittinen
2019-10-17 9:48 ` [RFC PATCH 06/13] regulator: bd71828: Add GPIO based run-level control for regulators Matti Vaittinen
2019-10-17 9:50 ` [RFC PATCH 07/13] regulator: bd71828: enhanced run-level support Matti Vaittinen
2019-10-17 9:51 ` [RFC PATCH 08/13] regulator: bd71828: Support in-kernel APIs to change run-level Matti Vaittinen
2019-10-17 9:52 ` [RFC PATCH 09/13] mfd: rtc: support RTC on ROHM BD71828 with BD70528 driver Matti Vaittinen
2019-10-17 10:12 ` Alexandre Belloni
2019-10-17 10:36 ` Vaittinen, Matti
2019-10-17 10:48 ` Alexandre Belloni
2019-10-21 5:29 ` Vaittinen, Matti
2019-10-23 10:27 ` Vaittinen, Matti
2019-10-29 13:50 ` Alexandre Belloni
2019-10-29 14:08 ` Vaittinen, Matti
2019-10-17 9:53 ` [RFC PATCH 10/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
2019-10-17 12:45 ` Bartosz Golaszewski
2019-10-21 7:00 ` Vaittinen, Matti
2019-10-21 14:36 ` Bartosz Golaszewski
2019-10-21 14:56 ` Vaittinen, Matti
2019-10-22 13:19 ` Vaittinen, Matti
2019-10-17 9:53 ` [RFC PATCH 11/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC Matti Vaittinen
2019-10-17 14:04 ` Dan Murphy
2019-10-17 14:28 ` Alexandre Belloni
2019-10-21 8:00 ` Vaittinen, Matti
2019-10-21 19:09 ` Jacek Anaszewski
2019-10-22 12:40 ` Vaittinen, Matti
2019-10-22 17:40 ` Jacek Anaszewski
2019-10-23 8:37 ` Vaittinen, Matti
2019-10-23 21:59 ` Jacek Anaszewski
2019-10-24 8:15 ` Vaittinen, Matti
2019-10-24 22:04 ` Jacek Anaszewski
2019-10-25 7:07 ` Vaittinen, Matti
2019-10-25 13:24 ` Rob Herring
2019-10-25 14:37 ` Vaittinen, Matti
2019-10-25 15:47 ` Rob Herring
2019-10-29 13:29 ` Vaittinen, Matti [this message]
2019-10-17 9:55 ` [RFC PATCH 12/13] dt-bindings: mfd: Document ROHM BD71282 bindings Matti Vaittinen
2019-10-17 14:18 ` Dan Murphy
2019-10-21 8:03 ` Vaittinen, Matti
2019-10-17 9:57 ` [RFC PATCH 13/13] dt-bindings: regulator: Document ROHM BD71282 regulator bindings Matti Vaittinen
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=81291f685a52002352b68bfc3749e2ed09c03ca0.camel@fi.rohmeurope.com \
--to=matti.vaittinen@fi.rohmeurope.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=bgolaszewski@baylibre.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mazziesaccount@gmail.com \
--cc=mturquette@baylibre.com \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
/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).