LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dan Murphy <dmurphy@ti.com>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>
Cc: <robh+dt@kernel.org>, <mark.rutland@arm.com>, <afd@ti.com>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-leds@vger.kernel.org>
Subject: Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Date: Mon, 14 May 2018 15:07:55 -0500	[thread overview]
Message-ID: <7d399662-9806-7bb2-e27f-de66557d043c@ti.com> (raw)
In-Reply-To: <2dd155f5-ce82-88b2-699e-897ef7d55fee@gmail.com>

Jacek

On 05/11/2018 03:27 PM, Jacek Anaszewski wrote:
> Dan,
> 
> On 05/11/2018 02:12 PM, Dan Murphy wrote:
>> Jacek
>>
>> Thanks for the review
>>
>> On 05/10/2018 03:17 PM, Jacek Anaszewski wrote:
>>> Hi Dan,
>>>
>>> On 05/10/2018 09:10 PM, Dan Murphy wrote:
>>>> On 05/10/2018 02:06 PM, Dan Murphy wrote:
>>>>> Pavel
>>>>>
>>>>> On 05/10/2018 01:54 PM, Pavel Machek wrote:
>>>>>> Hi!
>>>>>>
>>>>>>> Introduce the device tree bindings for the lm3601x
>>>>>>> family of LED torch, flash and IR drivers.
>>>>>>>
>>>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>>>>
>>>>>> Better, thanks.
>>>>>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>>>>>>> @@ -0,0 +1,50 @@
>>>>>>> +* Texas Instruments - lm3601x Single-LED Flash Driver
>>>>>>
>>>>>> Ok, so is it single-LED driver, or can it driver ir & white LEDs at
>>>>>> the same time?
>>>>>
>>>>> It is a single LED driver.  It can drive a Torch white LED or IR LED indefinitely or if the driver
>>>>> is programmed to strobe mode the driver will drive the configured LED for the flash timeout specified.
>>>>>
>>>>> Basically a flash and a flash light. IR or White LED.
>>>>>
>>>>>
>>>>>>
>>>>>>> +Example:
>>>>>>> +led-controller@64 {
>>>>>>> +    compatible = "ti,lm36010";
>>>>>>> +    #address-cells = <1>;
>>>>>>> +    #size-cells = <0>;
>>>>>>> +    reg = <0x64>;
>>>>>>> +
>>>>>>> +    led@0 {
>>>>>>> +        reg = <0>;
>>>>>>> +        label = "white:torch";
>>>>>>> +        led-max-microamp = <10000>;
>>>>>>> +    };
>>>>>>> +
>>>>>>> +    led@1 {
>>>>>>> +        reg = <1>;
>>>>>>> +        label = "white:flash";
>>>>>>> +        flash-max-microamp = <10000>;
>>>>>>> +        flash-max-timeout-us = <800>;
>>>>>>> +    };
>>>>>>
>>>>>> Is this realistic config? I'd expect flash to use more power than
>>>>>> torch, and would expect longer timeout than 0.8msec.
>>>>>
>>>>> Timeout in the spreadsheet is ms I will update this example and code
>>>>> Current in the spreadsheet is mA I will update this example and code
>>>>>
>>>>>>
>>>>>> Also.. if this is physically one white LED, it should not be
>>>>>> spread over reg = <0> and reg = <1>...
>>>>>
>>>>> If the torch LED and strobe LED are the same LED how do I expose them both to the user.
>>>>> It is up to consumer to configure the required interfaces they want to expose to the filesystem.
>>>
>>> LED flash class interface is prepared for it.
>>> led_clasdev_flash_register() internally calls led_classdev_register(),
>>> so there is brightness file available for torch related operations.
>>
>> Yes the flash class may handle this and expose the brightness node but the HW has two different registers to set the
>> corresponding brightness so one set brightness node does not work.
>> There is no way to differentiate between the strobe brightness (register 4) and the torch brightness (register 3).
> 
> Hmm? There is brightness file (with brightness_set{_blocking} op) from
> LED class and flash_brightness file (with flash_brightness_set op) from
> LED class flash.
> 
> I've only now realized that you're not using flash_brightness_set op for
> the "strobe_node" in your driver. I assume that you overlooked it.
> Please don't introduce "strobe_brightness" naming convention - we
> already have "flash_brightness" for that.
> 
>> When the enable register is written the driver will read the corresponding register and set
>> the current for the LED.
>>
>> This is why I separated out the strobe from the torch into 2 different LED nodes.
>>
>> I cannot seem to find the data sheet on line for the max77693 so I cannot verify that the device only has
>> a single brightness register for both torch and strobe.
> 
> It wasn't openly available at least at the time when I had an access
> to it.
> 
> But - please look at the functions max77693_set_torch_current() and
> max77693_set_flash_current(). The device has separate registers
> for torch and flash brightnesses.


I have looked at these functions and the parse dt function that dictates if there is 1 fled or 2 fled.
I am having trouble associating what these mean because the led-sources is being used to define how many LEDs.

In the common.txt it says
"- led-sources : List of device current outputs the LED is connected to. The
		outputs are identified by the numbers that must be defined
		in the LED device binding documentation."

I cannot find the max77693 dt documentation or even a dt file that defines what the led-sources could be defined as.
In addition, per the common.txt, the led sources should define the current outputs the LED is connected to.

Is one to assume that it is referring to the physical current pin connection or the devices internal current routing?

When I first referenced this driver as template driver it was misleading to say fled1 and fled2 as I took it to mean, and I still do, that the
driver supports 2 LED connections and not a single output pin with different internal current routing.

Without the data sheet or the dt documentation it makes understanding a little difficult.

I will fix it up how ever you would like it to be but I am thinking we need to fix up the max77693 as well so we can have 2 reference
drivers.  It is very difficult to derive the driver without a public version of the data sheet.

Dan

> 
>>>>> Maybe they don't want the strobe feature and just want LED on/off and switch between IR and White.
>>>>>
>>>>> The IR is driven via a different output pin.
>>>>
>>>> Correction.  There is only one LED drive pin.  The mode selected determines how the device will drive the
>>>> LED.  So you may have one device to drive a Torch and another device to drive the LED.
>>>
>>> But only one type of LED can be soldered on the board at a time, right?
>>> If yes, then this is clearly a DT related configuration, and only
>>> one child DT node should be defined for given board.
>>
>> But see above.  There is not a clean way to expose the torch/ir and strobe separately.
>>
>> Dan
>>
>>
>>>
>>>> Strobe is available in either case but not always required if strobe is not desired by the customer hence
>>>> why I have a separate DT node for it.
>>>>
>>>> Dan
>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>                                      Pavel
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
------------------
Dan Murphy

  reply	other threads:[~2018-05-14 20:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10 17:47 Dan Murphy
2018-05-10 17:47 ` [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver Dan Murphy
2018-05-10 20:48   ` Jacek Anaszewski
2018-05-11 11:56     ` Dan Murphy
2018-05-11 20:26       ` Jacek Anaszewski
2018-05-14 19:40       ` Dan Murphy
2018-05-14 19:49         ` Andy Shevchenko
2018-05-14 20:05         ` Pavel Machek
2018-05-14 20:13           ` Dan Murphy
2018-05-14 20:16             ` Pavel Machek
2018-05-14 20:31               ` Dan Murphy
2018-05-14 20:05         ` Jacek Anaszewski
2018-05-14 20:09           ` Dan Murphy
2018-05-10 18:54 ` [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver Pavel Machek
2018-05-10 19:06   ` Dan Murphy
2018-05-10 19:10     ` Dan Murphy
2018-05-10 20:17       ` Jacek Anaszewski
2018-05-11 12:12         ` Dan Murphy
2018-05-11 20:27           ` Jacek Anaszewski
2018-05-14 20:07             ` Dan Murphy [this message]
2018-05-14 20:48               ` Jacek Anaszewski
2018-05-10 20:50 ` Jacek Anaszewski

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=7d399662-9806-7bb2-e27f-de66557d043c@ti.com \
    --to=dmurphy@ti.com \
    --cc=afd@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --subject='Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver' \
    /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

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).