Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934145AbcKJPLy (ORCPT ); Thu, 10 Nov 2016 10:11:54 -0500 Received: from muru.com ([72.249.23.125]:58632 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933480AbcKJPLx (ORCPT ); Thu, 10 Nov 2016 10:11:53 -0500 Date: Thu, 10 Nov 2016 08:11:49 -0700 From: Tony Lindgren To: Hans de Goede Cc: Jacek Anaszewski , linux-leds@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: PM regression with LED changes in next-20161109 Message-ID: <20161110151149.GB27724@atomide.com> References: <20161109192301.GS26979@atomide.com> <621758ce-dd3f-41ad-d9b8-b8e34538700e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <621758ce-dd3f-41ad-d9b8-b8e34538700e@redhat.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1216 Lines: 36 * Hans de Goede [161110 01:35]: > Hi, > > On 09-11-16 20:23, Tony Lindgren wrote: > > 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. > > Do you have any blinking LEDs or LED triggers defined on the system ? There are some configured in the dts file: $ grep -i led arch/arm/boot/dts/*torpedo*.dts* And the gpio controlled led1 is configured to blink with linux,default-trigger = "cpu0". > > Reverting this patch fixes the issue. Any ideas? > > All I can think of is something calling led_set_brightness quite often, > the patch in question makes led_set_brightness somewhat more expensive, > but it should not cause such a big difference unless something is > really calling led_set_brightness quite often maybe something is calling > it with the same value all the time ? I don't think this one has any brightness control. Regards, Tony