[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161110202910.GE28832@amd>
Date: Thu, 10 Nov 2016 21:29:10 +0100
From: Pavel Machek <pavel@....cz>
To: Tony Lindgren <tony@...mide.com>
Cc: Jacek Anaszewski <j.anaszewski@...sung.com>,
Hans de Goede <hdegoede@...hat.com>,
Jacek Anaszewski <jacek.anaszewski@...il.com>,
linux-leds@...r.kernel.org, linux-omap@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Darren Hart <dvhart@...radead.org>
Subject: Re: PM regression with LED changes in next-20161109
On Thu 2016-11-10 10:55:37, Tony Lindgren wrote:
> * Pavel Machek <pavel@....cz> [161110 09:29]:
> > 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?
>
> Yeah one of them seems to have cpu0 as the default trigger.
Aha. Its quite obvious we don't want to notify sysfs each time that
one is toggled, right?
IMO brightness should display max brightness for the trigger, as Hans
suggested, anything else is madness for trigger such as cpu activity.
Thanks and best regards,
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