Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1162202AbbKTJXB (ORCPT <rfc822;w@1wt.eu>);
	Fri, 20 Nov 2015 04:23:01 -0500
Received: from mailout2.w1.samsung.com ([210.118.77.12]:14233 "EHLO
	mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1161376AbbKTJW4 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 20 Nov 2015 04:22:56 -0500
X-AuditID: cbfec7f4-f79026d00000418a-fe-564ee66dceee
Message-id: <564EE66C.5010709@samsung.com>
Date: Fri, 20 Nov 2015 10:22:52 +0100
From: Jacek Anaszewski <j.anaszewski@samsung.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804
 Thunderbird/17.0.8
MIME-version: 1.0
To: "Kim, Milo" <milo.kim@ti.com>
Cc: devicetree@vger.kernel.org, lee.jones@linaro.org,
        linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org
Subject: Re: [PATCH RESEND 15/16] leds: add LM3633 driver
References: <1446441875-1256-1-git-send-email-milo.kim@ti.com>
 <1446441875-1256-16-git-send-email-milo.kim@ti.com>
 <5638DD99.9070502@samsung.com> <56419F0C.90009@ti.com>
In-reply-to: <56419F0C.90009@ti.com>
Content-type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsVy+t/xK7q5z/zCDJpXyVjMP3KO1eL+16OM
	Fpd3zWGz2PpmHaPF8l/rWBxYPe5c28PmcfzGdiaPz5vkApijuGxSUnMyy1KL9O0SuDKu9Lxl
	LNjAV/Hi9R/2BsY+7i5GTg4JAROJc0s/MELYYhIX7q1nA7GFBJYySvT88e1i5AKynzFKTG+b
	xgSS4BXQklgzvZUFxGYRUJXYens2WAObgKHEzxevwWpEBSIk/pzexwpRLyjxY/I9sHoRAUWJ
	j2d2gS1jFiiQmLNnGZgtLGApcbvzFyPEsrWMEm92fABr5hRQkdiw9RczRIOtxIL361ggbHmJ
	zWveMk9gFJiFZMcsJGWzkJQtYGRexSiaWppcUJyUnmuoV5yYW1yal66XnJ+7iRESvl92MC4+
	ZnWIUYCDUYmHt0HcL0yINbGsuDL3EKMEB7OSCO9SP6AQb0piZVVqUX58UWlOavEhRmkOFiVx
	3rm73ocICaQnlqRmp6YWpBbBZJk4OKUaGNnPPFr8PltJxujgSSNNg4r+QPOvb6+vkF4TZTex
	tOvMi+lHomYqegmsDtfsO30w7HjNDwW3EPfqbz66N4T09i6RVTp49W6B10nP9A2bG72W9qQa
	TZyz58j1nS3X3DUYRewyJOZc17u+9KOSvxwLu6yxp2y03+7HJ8wqt/NtfR62PKr5F5f9UyWW
	4oxEQy3mouJEAJR+BnFbAgAA
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2043
Lines: 47

On 11/10/2015 08:38 AM, Kim, Milo wrote:
[...]
>>> +                cat /sys/class/leds/<led>/pattern_levels
>>> +                low brightness: 0, high brightness: 255
>>> +
>>> +What:        /sys/class/leds/<led>/run_pattern
>>> +Date:        Oct 2015
>>> +KernelVersion:    4.3
>>> +Contact:    Milo Kim <milo.kim@ti.com>
>>> +Description:    write only
>>> +                After 'pattern_times' and 'pattern_levels' are updated,
>>> +                run the pattern by writing 1 to 'run_pattern'.
>>> +                To stop running pattern, writes 0 to 'run_pattern'.
>>
>> I wonder how registering an in-driver trigger would work. It would
>> allow for hiding above pattern attributes when the trigger is inactive,
>> and thus making the sysfs interface more transparent. You could avoid
>> the need for run_pattern attribute, as setting the trigger would itself
>> activate the pattern, and setting brightness to 0 would turn it off.
>
> I like this idea, let me try to fix it.

After thinking it over, I came to conclusion that implementing it as
an in-driver trigger is not a proper way to go, since triggers are
defined as kernel based source of LED events.

This is somehow abused in case of timer trigger which takes hardware 
blinking feature as a first choice and applies software blinking as
a fallback only. To be consistent with that, we could go for adding
generic pattern trigger and add a led_pattern_set() API, similarly
to existing led_blink_set().

The problem is that different LED controllers may implement blinking
patterns that are configured with different set of parameters. This
subject would definitely require thorough analysis.

For now, please just expose pattern settings as separate sysfs
attributes of a LED class device.

-- 
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/