[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141210105051.GN15559@valkosipuli.retiisi.org.uk>
Date: Wed, 10 Dec 2014 12:50:51 +0200
From: Sakari Ailus <sakari.ailus@....fi>
To: Jacek Anaszewski <j.anaszewski@...sung.com>
Cc: linux-leds@...r.kernel.org, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org, kyungmin.park@...sung.com,
b.zolnierkie@...sung.com, pavel@....cz, cooloney@...il.com,
rpurdie@...ys.net, s.nawrocki@...sung.com, robh+dt@...nel.org,
pawel.moll@....com, mark.rutland@....com,
ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
Andrzej Hajda <a.hajda@...sung.com>,
Lee Jones <lee.jones@...aro.org>,
Chanwoo Choi <cw00.choi@...sung.com>,
devicetree@...r.kernel.org
Subject: Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim
max77693
Hi Jacek,
On Wed, Dec 10, 2014 at 11:02:07AM +0100, Jacek Anaszewski wrote:
> Hi Sakari,
>
> On 12/04/2014 12:40 PM, Jacek Anaszewski wrote:
>
> >On 12/04/2014 11:07 AM, Sakari Ailus wrote:
> >>Hi Jacek,
> >>
> >>On Wed, Dec 03, 2014 at 05:06:41PM +0100, Jacek Anaszewski wrote:
> >>>This patch adds device tree binding documentation for
> >>>the flash cell of the Maxim max77693 multifunctional device.
> >>>
> >>>Signed-off-by: Jacek Anaszewski <j.anaszewski@...sung.com>
> >>>Signed-off-by: Andrzej Hajda <a.hajda@...sung.com>
> >>>Acked-by: Kyungmin Park <kyungmin.park@...sung.com>
> >>>Cc: Lee Jones <lee.jones@...aro.org>
> >>>Cc: Chanwoo Choi <cw00.choi@...sung.com>
> >>>Cc: Bryan Wu <cooloney@...il.com>
> >>>Cc: Richard Purdie <rpurdie@...ys.net>
> >>>Cc: Rob Herring <robh+dt@...nel.org>
> >>>Cc: Pawel Moll <pawel.moll@....com>
> >>>Cc: Mark Rutland <mark.rutland@....com>
> >>>Cc: Ian Campbell <ijc+devicetree@...lion.org.uk>
> >>>Cc: Kumar Gala <galak@...eaurora.org>
> >>>Cc: <devicetree@...r.kernel.org>
> >>>---
> >>> Documentation/devicetree/bindings/mfd/max77693.txt | 89
> >>>++++++++++++++++++++
> >>> 1 file changed, 89 insertions(+)
> >>>
> >>>diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
> >>>b/Documentation/devicetree/bindings/mfd/max77693.txt
> >>>index 01e9f30..25a6e78 100644
> >>>--- a/Documentation/devicetree/bindings/mfd/max77693.txt
> >>>+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
> >>>@@ -41,7 +41,66 @@ Optional properties:
> >>> To get more informations, please refer to documentaion.
> >>> [*] refer Documentation/devicetree/bindings/pwm/pwm.txt
> >>>
> >>>+- led : the LED submodule device node
> >>>+
> >>>+There are two led outputs available - fled1 and fled2. Each of them can
> >>>+control a separate led or they can be connected together to double
> >>>+the maximum current for a single connected led. One led is represented
> >>>+by one child node.
> >>>+
> >>>+Required properties:
> >>>+- compatible : Must be "maxim,max77693-led".
> >>>+
> >>>+Optional properties:
> >>>+- maxim,fleds : Array of current outputs in order: fled1, fled2.
> >>>+ Note: both current outputs can be connected to a single led
> >>>+ Possible values:
> >>>+ MAX77693_LED_FLED_UNUSED - the output is left disconnected,
> >>>+ MAX77693_LED_FLED_USED - a diode is connected to the output.
> >>
> >>As you have a LED sub-nodes for each LED already, isn't this redundant?
> >
> >Well, it seems so :)
>
> I agreed here recklessly. This property allows to describe the
If this is reckless then we're doing very, very well. :-D
> situation when one LED is connected to both outputs. Single sub-node
> can describe two type of designs: one LED connected to a single
> output or one LED connected to both outputs. Therefore additional
> property is needed to assess what is the actual case.
Which output do you say such LED is connected then?
I wonder if the reg property could be made an array, so you could say the
LED is connected to this and that output.
The advantage would be that this still works even if you have three outputs.
--
Regards,
Sakari Ailus
e-mail: sakari.ailus@....fi XMPP: sailus@...iisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists