Re: PM regression with LED changes in next-20161109

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

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.
...
> >                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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]