Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935048AbcKJQ3b (ORCPT ); Thu, 10 Nov 2016 11:29:31 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:56125 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934925AbcKJQ3a (ORCPT ); Thu, 10 Nov 2016 11:29:30 -0500 Date: Thu, 10 Nov 2016 17:29:25 +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: PM regression with LED changes in next-20161109 Message-ID: <20161110162925.GA28832@amd> References: <20161109192301.GS26979@atomide.com> <28234714-3994-6747-9cf8-1ff0b3257f7a@gmail.com> <5bd5333e-0dbb-6333-0a48-ca4d3a990f9c@samsung.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <5bd5333e-0dbb-6333-0a48-ca4d3a990f9c@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 Content-Length: 1805 Lines: 57 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > >>>Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing > >>>the sysfs brightness attr for changes.") breaks runtime PM for me. > >>> > >>>On my omap dm3730 based test system, idle power consumption is over 70 > >>>times higher now with this patch! It goes from about 6mW for the core > >>>system to over 440mW during idle meaning there's some busy timer now > >>>active. > >>> > >>>Reverting this patch fixes the issue. Any ideas? Are you using any LED that toggles with high frequency? Like perhaps LED that is lit when CPU is active? > >So a user can do "echo 128 > brightness && cat brightness" and > >get out 0, or 128, depending purely on timing. =2E.. > > Reading from this file while a trigger is active returns > >the > > top brightness trigger is going to use. Yes, that sounds sane. > It seems that we should get back to your initial approach. i.e. only > brightness changes caused by hardware should be reported. I don't think enabling poll() here is good idea. Some hardware won't be able to tell you that it changed the state. Returning maximum brightness trigger is going to use seems easier/better. Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlgkoGUACgkQMOfwapXb+vIeUACfR+m0VBKjiMJ/lvoDj5sKGhVo PjYAmwcXhoSwYjC3N3GJ6sCs022yU9eq =wFaW -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/--