[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160401150331.GG11860@amd>
Date: Fri, 1 Apr 2016 17:03:31 +0200
From: Pavel Machek <pavel@....cz>
To: Jacek Anaszewski <j.anaszewski@...sung.com>
Cc: Heiner Kallweit <hkallweit1@...il.com>, pali.rohar@...il.com,
sre@...nel.org, khilman@...nel.org, aaro.koskinen@....fi,
ivo.g.dimitrov.75@...il.com,
Patrik Bachan <patrikbachan@...il.com>, serge@...lyn.com,
Greg KH <greg@...ah.com>, linux-leds@...r.kernel.org,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux USB Mailing List <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color
LED's
Hi!
> >>The main drawback is that you can't set the colour at one go,
> >>but have to set brightness of each LED class device (R,G,B)
> >>separately. It incurs delays between setting each colour component.
> >
> >Yeah. Well, on some hardware, that's just the way it is. If the leds
> >are separate devices on i2c, you can't really set them in one go.
>
> Delays can occur even if the LEDs are controlled by the same device.
> Brightness of each LED class device is set with separate system
> call and there will be always some time shift between particular I2C
> transmissions that set the brightness for each sub-LED.
>
> If the three sub-LEDs were controlled by a single LED class device
> then we could setup the brightness of each sub-LED with single I2C
> transmission.
Ok, well, yes, maybe you could.
You can still do that with the proposed interface, but yes, it will be
trickier.
OTOH proposed interface will also help with the hardware pattern
support, will work with existing leds, and matches the way hardware
works. So I believe it is worth it.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Powered by blists - more mailing lists