lkml.org 
[lkml]   [2018]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 5/7] dt-bindings: ti-lmu: Modify dt bindings for the LM3633
On Wed 2018-10-24 09:35:06, Rob Herring wrote:
> On Wed, Oct 24, 2018 at 11:23:28AM +0200, Pavel Machek wrote:
> > On Tue 2018-10-23 12:06:21, Dan Murphy wrote:
> > > The LM3633 is a single function LED driver. The single function LED
> > > driver needs to reside in the LED directory as a dedicated LED driver
> > > and not as a MFD device. The device does have common brightness and ramp
> > > features and those can be accomodated by a TI LMU framework.
> > >
> > > The LM3633 dt binding needs to be moved from the ti-lmu.txt and a dedicated
> > > LED dt binding needs to be added. The new LM3633 LED dt binding will then
> > > reside in the Documentation/devicetree/bindings/leds directory and follow the
> > > current LED and general bindings guidelines.
> >
> > What?
> >
> > > .../devicetree/bindings/leds/leds-lm3633.txt | 102 ++++++++++++++++++
> > > .../devicetree/bindings/mfd/ti-lmu.txt | 48 ---------
> > > 2 files changed, 102 insertions(+), 48 deletions(-)
> > > create mode 100644
> > > Documentation/devicetree/bindings/leds/leds-lm3633.txt
> >
> > > index 920f910be4e9..573e88578d3d 100644
> > > --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> > > +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> > > @@ -7,7 +7,6 @@ TI LMU driver supports lighting devices below.
> > > LM3532 Backlight
> > > LM3631 Backlight and regulator
> > > LM3632 Backlight and regulator
> > > - LM3633 Backlight, LED and fault monitor
> > > LM3695 Backlight
> >
> > Are you seriously proposing to take one binding and split it into 6
> > copy&pasted ones?
> >
> > That's not the way we do development. NAK.
> >
> > We don't want to have copy & pasted code. We also don't want to have
> > copy & pasted bindings. Nor changelogs, for that matter.
>
> I looked at the LM3633 and LM3632 datasheets. They look quite different
> to me and should be separate IMO. Just looking at different LED
> functions and GPIO control lines is enough to make that determination.
> The LM3697 looks like a subset of LM3633 at least at a schematic
> diagram level, so maybe those can be shared.

Well, they have blocks in common, and are currently handled by one
driver. Two .c files proposed here shared 80% code when I reviewed
previous version. Original merge documentation is:

https://groups.google.com/forum/#!msg/fa.linux.kernel/hWvxahP7INw/Y2EDZmjoAQAJ

TI LMU(Lighting Management Unit) driver supports lighting devices
below.

Enable pin Backlights HWMON LEDs Regulators
---------- ---------- ----- ---- ------------
LM3532 o o x x x
LM3631 o o x x 5 regulators
LM3632 o o x x 3 regulators
LM3633 o o o o x
LM3695 o o x x x
LM3697 o o o x x


I thought I understood that table, but maybe I'm confused. Anyway,
there seemed to be "enough" to share.

> While we could litter the binding with conditions on properties
> depending on specific compatible strings (such as which GPIO properties
> apply to which compatible), that is going to be problematic down the
> line when we convert to json-schema[1].

Well, situation where different devices share common features /
function blocks is going to be somehow common. Not sure how to solve
it in json, maybe the properties can simply be marked optional?, but I
guess it will need solving somehow.

> [1] https://lkml.org/lkml/2018/10/5/883

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-10-24 20:38    [W:0.071 / U:1.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site