[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170605211609.GA9035@amd>
Date: Mon, 5 Jun 2017 23:16:09 +0200
From: Pavel Machek <pavel@....cz>
To: Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc: fenglinw@...eaurora.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, Richard Purdie <rpurdie@...ys.net>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
subbaram@...cinc.com, aghayal@....qualcomm.com, wruan@...cinc.com,
kgunda@....qualcomm.com
Subject: Re: [PATCH V2 1/2] leds: leds-qti-rgb: Add LED driver for QTI
TRI_LED module
Hi!
> Generally I came to a conclusion that it will be best to register
> additional LED RGB class device in an addition to three LED class
> devices representing each color. In order to avoid hard to solve
> locking problems I propose to allow for simultaneous access to LED
> class devices and LED RGB class device gathering them.
>
> All in all, currently we also don't give an exclusive access to
> a particular LED class device, which always can lead to overwriting
> current brightness by another process. These issues must be arbitrated
> by user space.
>
> I propose that LED RGB class device exposed following files:
>
> - red_brightness
> - green_brightness
> - blue_brightness
> - latch_color
Actually, I'd just do single file, "rgb_brightness" with 3
values. Overhead of writing 3 values is pretty much 0.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists