From: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
To: Oliver Schinagl <oliver+list@schinagl.nl>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>,
Hans Verkuil <hansverk@cisco.com>,
"media-workshop@linuxtv.org" <media-workshop@linuxtv.org>,
Sakari Ailus <sakari.ailus@iki.fi>,
Thierry Reding <thierry.reding@gmail.com>,
Bryan Wu <bryan.wu@canonical.com>,
Richard Purdie <rpurdie@rpsys.net>,
linux-leds@vger.kernel.org, linux-pwm@vger.kernel.org,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: V2: Agenda for the Edinburgh mini-summit
Date: Mon, 23 Sep 2013 22:27:06 +0200 [thread overview]
Message-ID: <5240A41A.6050207@gmail.com> (raw)
In-Reply-To: <52406E5C.2020709@schinagl.nl>
On 09/23/2013 06:37 PM, Oliver Schinagl wrote:
> On 09/23/13 16:45, Sylwester Nawrocki wrote:
>> Hi,
>>
>> I would like to have a short discussion on LED flash devices support
>> in the kernel. Currently there are two APIs: the V4L2 and LED class
>> API exposed by the kernel, which I believe is not good from user space
>> POV. Generic applications will need to implement both APIs. I think we
>> should decide whether to extend the led class API to add support for
>> more advanced LED controllers there or continue to use the both APIs
>> with overlapping functionality.
>> There has been some discussion about this on the ML, but without any
>> consensus reached [1].
>
> What about the linux-pwm framework and its support for the backlight via
> dts?
>
> Or am I talking way to uninformed here. Copying backlight to flashlight
> with some minor modification sounds sensible in a way...
I'd assume we don't need yet another user interface for the LEDs ;) AFAICS
the PWM subsystem exposes pretty much raw interface in sysfs. The PWM LED
controllers are already handled in the leds-class API, there is the
leds_pwm
driver (drivers/leds/leds-pwm.c).
I'm adding linux-pwm and linux-leds maintainers at Cc so someone may correct
me if I got anything wrong.
Presumably, what we need is a few enhancements to support in a standard way
devices like MAX77693, LM3560 or MAX8997. There is already a led class
driver
for the MAX8997 LED controller (drivers/leds/leds-max8997.c), but it
uses some
device-specific sysfs attributes.
Thus similar devices are currently being handled by different subsystems.
The split between the V4L2 Flash and the leds class API WRT to Flash LED
controller drivers is included in RFC [1], it seems still up to date.
>> [1] http://www.spinics.net/lists/linux-leds/msg00899.html
--
Thanks,
Sylwester
next parent reply other threads:[~2013-09-23 20:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201309101134.32883.hansverk@cisco.com>
[not found] ` <52405427.6000002@samsung.com>
[not found] ` <52406E5C.2020709@schinagl.nl>
2013-09-23 20:27 ` Sylwester Nawrocki [this message]
2013-09-24 9:20 ` V2: Agenda for the Edinburgh mini-summit Thierry Reding
2013-10-07 21:06 ` Sakari Ailus
2013-10-07 22:24 ` [media-workshop] " Laurent Pinchart
2013-10-11 0:02 ` Bryan Wu
2013-10-11 7:38 ` Laurent Pinchart
2013-10-15 18:37 ` Bryan Wu
2013-10-15 18:50 ` Laurent Pinchart
2013-10-15 20:55 ` Bryan Wu
2013-10-15 19:03 ` Sylwester Nawrocki
2013-10-16 1:49 ` Milo Kim
2013-10-16 10:24 ` Sylwester Nawrocki
2013-10-16 17:17 ` Bryan Wu
2013-10-16 23:36 ` Milo Kim
2013-10-16 23:54 ` Bryan Wu
2013-10-16 23:56 ` Bryan Wu
2013-10-17 0:12 ` Andy Walls
2013-10-19 0:17 ` Bryan Wu
[not found] ` <CAPybu_2KRF_VHkjCEV8d7YOaZo27QJ=TxGTsUOeWO5X_tp8Ozw@mail.gmail.com>
2013-10-21 18:40 ` Bryan Wu
2013-10-21 18:52 ` Hans Verkuil
[not found] ` <CAPybu_1NZ-CfNkMt_stev5L9oL1MqSAhV03jQW7QoF=q4c2JzQ@mail.gmail.com>
2013-10-21 19:39 ` Hans Verkuil
2013-10-22 9:50 ` Hans Verkuil
2013-09-24 9:32 ` Thierry Reding
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=5240A41A.6050207@gmail.com \
--to=sylvester.nawrocki@gmail.com \
--cc=bryan.wu@canonical.com \
--cc=hansverk@cisco.com \
--cc=linux-leds@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=media-workshop@linuxtv.org \
--cc=oliver+list@schinagl.nl \
--cc=rpurdie@rpsys.net \
--cc=s.nawrocki@samsung.com \
--cc=sakari.ailus@iki.fi \
--cc=thierry.reding@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).