lkml.org 
[lkml]   [2019]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH 11/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC
Date
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
\
 
 \ /
  Last update: 2019-10-29 14:29    [W:0.162 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site