From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751937AbcKOLL7 (ORCPT ); Tue, 15 Nov 2016 06:11:59 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:55678 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751127AbcKOLL5 (ORCPT ); Tue, 15 Nov 2016 06:11:57 -0500 Date: Tue, 15 Nov 2016 12:11:54 +0100 From: Pavel Machek To: Jacek Anaszewski Cc: Hans de Goede , Jacek Anaszewski , Tony Lindgren , linux-leds@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Darren Hart Subject: Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Message-ID: <20161115111154.GA5482@amd> References: <3eb60c78-d891-27e5-6b7b-a54a5b547a1c@redhat.com> <9b476f85-d45e-deb6-335d-fc56f6d90350@redhat.com> <127cdd42-6fd8-c671-60b7-3826b351577f@samsung.com> <15cafbf5-d842-e184-2fd4-65f8272f505a@redhat.com> <20161115103133.GA22860@amd> <4e392d5d-eb10-f285-517e-976a55c3e318@samsung.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <4e392d5d-eb10-f285-517e-976a55c3e318@samsung.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue 2016-11-15 11:58:06, Jacek Anaszewski wrote: > On 11/15/2016 11:31 AM, Pavel Machek wrote: > >Hi! > > > >>>Hmm, v4 still calls led_notify_brightness_change(led_cdev) > >>>from both __led_set_brightness() and __led_set_brightness_blocking(). > >> > >>Ugh, I see I accidentally send a v4 twice, instead of > >>calling the version which dropped those called v5 as > >>I should have, sorry. > >> > >>The v4 which I would like to see merged, the one with > >>those calls dropped, is here: > >> > >>https://patchwork.kernel.org/patch/9423093/ > > > >Please, lets fix this properly. > > > >The LED you are talking about _has_ a trigger, implemented in > >hardware. That trigger can change LED brightness behind kernel's (and > >userspace's) back. Don't pretend the trigger does not exist, it does. > > > >And when you do that, you'll have nice place to report changes to > >userspace -- trigger can now export that information, and offer poll() > >interface. >=20 > Well, that sounds interesting. It is logically justifiable. Thanks. > I initially proposed exactly this solution, with recently > added userspace LED being a trigger listener. It seems a bit > awkward though. How would you listen to the trigger events? Trigger exposes a file in sysfs, with poll() working on that file (and probably read exposing the current brightness). Key difference is that only triggers where this makes sense (keyboard backlight) expose it and carry the overhead. CPU trigger would definitely not do this. Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlgq7XkACgkQMOfwapXb+vKutQCfYxrl1Z8VQqpuTfJOpRAQSZEp kvAAmQGKQf5bDFRcHyCi/wIP2QKPb99S =dZ2q -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q--