From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Various LED complexities was Re: [PATCH v5 05/26] leds: core: Add support for composing LED class device names Date: Thu, 4 Jul 2019 00:05:26 +0200 Message-ID: <20190703220526.GB876@amd> References: <20190609190803.14815-1-jacek.anaszewski@gmail.com> <20190609190803.14815-6-jacek.anaszewski@gmail.com> <643e3b10fe9d45b59ed063ffc6d578ff@AcuMS.aculab.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Return-path: Content-Disposition: inline In-Reply-To: <643e3b10fe9d45b59ed063ffc6d578ff@AcuMS.aculab.com> Sender: linux-kernel-owner@vger.kernel.org To: David Laight Cc: 'Linus Walleij' , Jacek Anaszewski , Linux LED Subsystem , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "linux-kernel@vger.kernel.org" , Rob Herring , Dmitry Torokhov , Guenter Roeck , Dan Murphy , Baolin Wang , Daniel Mack , Oleh Kravchenko , Sakari Ailus , Simon Shields List-Id: linux-leds@vger.kernel.org --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri 2019-06-28 13:30:30, David Laight wrote: > From: Linus Walleij > > Sent: 28 June 2019 09:46 > ... > > A problem with LEDs is that it invites bikeshedding because it is too > > relateable. >=20 > Bikeshedding leds :-) >=20 > It also isn't at all clear how to handle bi-colour and tri-colour leds. > ISTR the usual interface lets you set the brightness, but more often > leds are single brightness but multi-colour. > Eg the ethernet 'speed' led which is (usually) off/orange/green. >=20 > Changing the brightness either means changing the current or using PWM. > Both really require more hardware support than changing colours. >=20 > I've done some led driving (for a front panel) from a PLD (small FPGA). > As well as the obvious things I did: > - dim: 1/8th on at 80Hz. > - flash: 1/8th on at 4Hz. > - orange: 50-50 red-green at 80Hz on an RGB led. >=20 > There was also the 'ethernet activity' led which could either be driven > by the hardware, or forced on/off/flash by the driver. > If driven by the hardware, the software could read the current state. >=20 > None of this really fitted the Linux leds interface. Well, we are working on some of those :-). But lets discuss that in separate threads. In particular we are working on triggers and RGB LEDs. bi-color LEDs seem to handled as two separate LEDs. Not much expected to change there. =09 Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAl0dJqYACgkQMOfwapXb+vK3+gCgip2UEFe6NwueZy1C3k5AeG/n otAAnjpPCwHWvYp6ku5OriKI1CkGFCYr =31SK -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko--