Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 13:06, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! 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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 13:06, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! 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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

On 11/15/2016 03:30 PM, Hans de Goede wrote: Hi, On 15-11-16 15:04, Jacek Anaszewski wrote: On 11/15/2016 02:48 PM, Hans de Goede wrote: Hi, On 15-11-16 14:28, Jacek Anaszewski wrote: On 11/15/2016 01:06 PM, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! The LED

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

On 11/15/2016 03:30 PM, Hans de Goede wrote: Hi, On 15-11-16 15:04, Jacek Anaszewski wrote: On 11/15/2016 02:48 PM, Hans de Goede wrote: Hi, On 15-11-16 14:28, Jacek Anaszewski wrote: On 11/15/2016 01:06 PM, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! The LED

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 15:04, Jacek Anaszewski wrote: On 11/15/2016 02:48 PM, Hans de Goede wrote: Hi, On 15-11-16 14:28, Jacek Anaszewski wrote: On 11/15/2016 01:06 PM, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! The LED you are talking about _has_ a trigger,

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 15:04, Jacek Anaszewski wrote: On 11/15/2016 02:48 PM, Hans de Goede wrote: Hi, On 15-11-16 14:28, Jacek Anaszewski wrote: On 11/15/2016 01:06 PM, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! The LED you are talking about _has_ a trigger,

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

On 11/15/2016 02:48 PM, Hans de Goede wrote: Hi, On 15-11-16 14:28, Jacek Anaszewski wrote: On 11/15/2016 01:06 PM, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! The LED you are talking about _has_ a trigger, implemented in hardware. That trigger can change LED

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

On 11/15/2016 02:48 PM, Hans de Goede wrote: Hi, On 15-11-16 14:28, Jacek Anaszewski wrote: On 11/15/2016 01:06 PM, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! The LED you are talking about _has_ a trigger, implemented in hardware. That trigger can change LED

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 14:28, Jacek Anaszewski wrote: On 11/15/2016 01:06 PM, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! 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.

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 14:28, Jacek Anaszewski wrote: On 11/15/2016 01:06 PM, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! 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.

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

On 11/15/2016 01:06 PM, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! 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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

On 11/15/2016 01:06 PM, Hans de Goede wrote: Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! 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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

On Tue 2016-11-15 13:06:14, Hans de Goede wrote: > Hi, > > On 15-11-16 12:48, Pavel Machek wrote: > >Hi! > > > >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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

On Tue 2016-11-15 13:06:14, Hans de Goede wrote: > Hi, > > On 15-11-16 12:48, Pavel Machek wrote: > >Hi! > > > >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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! 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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 12:48, Pavel Machek wrote: Hi! 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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi! > >>>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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi! > >>>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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 12:11, Pavel Machek wrote: 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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 12:11, Pavel Machek wrote: 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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

HI, On 15-11-16 11:58, 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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

HI, On 15-11-16 11:58, 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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

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

Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

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

LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

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

LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

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

Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 11:01, Jacek Anaszewski wrote: Hi, On 11/14/2016 01:51 PM, Hans de Goede wrote: 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

Re: PM regression with LED changes in next-20161109

Hi, On 15-11-16 11:01, Jacek Anaszewski wrote: Hi, On 11/14/2016 01:51 PM, Hans de Goede wrote: 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

Re: PM regression with LED changes in next-20161109

Hi, On 11/14/2016 01:51 PM, Hans de Goede wrote: Hi, On 14-11-16 10:12, Jacek Anaszewski wrote: Hi, On 11/13/2016 02:52 PM, Hans de Goede wrote: Hi, On 13-11-16 12:44, Jacek Anaszewski wrote: Hi, On 11/12/2016 10:14 PM, Hans de Goede wrote: So I would like to propose creating a new

Re: PM regression with LED changes in next-20161109

Hi, On 11/14/2016 01:51 PM, Hans de Goede wrote: Hi, On 14-11-16 10:12, Jacek Anaszewski wrote: Hi, On 11/13/2016 02:52 PM, Hans de Goede wrote: Hi, On 13-11-16 12:44, Jacek Anaszewski wrote: Hi, On 11/12/2016 10:14 PM, Hans de Goede wrote: So I would like to propose creating a new

Re: PM regression with LED changes in next-20161109

Hi, On 14-11-16 10:12, Jacek Anaszewski wrote: Hi, On 11/13/2016 02:52 PM, Hans de Goede wrote: Hi, On 13-11-16 12:44, Jacek Anaszewski wrote: Hi, On 11/12/2016 10:14 PM, Hans de Goede wrote: So I would like to propose creating a new read-write user_brightness file. The write

Re: PM regression with LED changes in next-20161109

Hi, On 14-11-16 10:12, Jacek Anaszewski wrote: Hi, On 11/13/2016 02:52 PM, Hans de Goede wrote: Hi, On 13-11-16 12:44, Jacek Anaszewski wrote: Hi, On 11/12/2016 10:14 PM, Hans de Goede wrote: So I would like to propose creating a new read-write user_brightness file. The write

Re: PM regression with LED changes in next-20161109

Hi, On 11/13/2016 02:52 PM, Hans de Goede wrote: Hi, On 13-11-16 12:44, Jacek Anaszewski wrote: Hi, On 11/12/2016 10:14 PM, Hans de Goede wrote: So I would like to propose creating a new read-write user_brightness file. The write behavior would be 100% identical to the brightness file

Re: PM regression with LED changes in next-20161109

Hi, On 11/13/2016 02:52 PM, Hans de Goede wrote: Hi, On 13-11-16 12:44, Jacek Anaszewski wrote: Hi, On 11/12/2016 10:14 PM, Hans de Goede wrote: So I would like to propose creating a new read-write user_brightness file. The write behavior would be 100% identical to the brightness file

Re: PM regression with LED changes in next-20161109

Hi! > >Also, how would we read the > >brightness set by the firmware? We'd have to read brightness > >file, so still two files would have to be opened which is > >a second drawback of this approach. > > No, look carefully at the definition of the read behavior > I plan to put in the ABI doc: >

Re: PM regression with LED changes in next-20161109

Hi! > >Also, how would we read the > >brightness set by the firmware? We'd have to read brightness > >file, so still two files would have to be opened which is > >a second drawback of this approach. > > No, look carefully at the definition of the read behavior > I plan to put in the ABI doc: >

Re: Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109)

Hi! > >No, that's just adding more mess on the system. > > > >Here's better proposal: > > > >brightness (write): what we do today. (Mess, but too late to change it) > >(read): -Esomething or what we do today (if someone > >acutally uses it)

Re: Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109)

Hi! > >No, that's just adding more mess on the system. > > > >Here's better proposal: > > > >brightness (write): what we do today. (Mess, but too late to change it) > >(read): -Esomething or what we do today (if someone > >acutally uses it)

Re: PM regression with LED changes in next-20161109

Hi, On 13-11-16 12:44, Jacek Anaszewski wrote: Hi, On 11/12/2016 10:14 PM, Hans de Goede wrote: So I would like to propose creating a new read-write user_brightness file. The write behavior would be 100% identical to the brightness file (in code terms it will call the same store

Re: PM regression with LED changes in next-20161109

Hi, On 13-11-16 12:44, Jacek Anaszewski wrote: Hi, On 11/12/2016 10:14 PM, Hans de Goede wrote: So I would like to propose creating a new read-write user_brightness file. The write behavior would be 100% identical to the brightness file (in code terms it will call the same store

Re: PM regression with LED changes in next-20161109

Hi, On 11/12/2016 10:14 PM, Hans de Goede wrote: Hi, On 12-11-16 20:14, Jacek Anaszewski wrote: Why a dedicated file? Are we going to mirror brightness here wrt r/w (show/store) behavior ? If not userspace now needs 2 open fds which is not really nice. If we are and we are not going to use

Re: PM regression with LED changes in next-20161109

Hi, On 11/12/2016 10:14 PM, Hans de Goede wrote: Hi, On 12-11-16 20:14, Jacek Anaszewski wrote: Why a dedicated file? Are we going to mirror brightness here wrt r/w (show/store) behavior ? If not userspace now needs 2 open fds which is not really nice. If we are and we are not going to use

Re: Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109)

Hi, On 13-11-16 10:10, Pavel Machek wrote: On Sat 2016-11-12 09:03:42, Hans de Goede wrote: Hi, On 11-11-16 23:12, Pavel Machek wrote: Hi! Reason #1: Hmm. So userland can read the LED state, and it can get _some_ value back, but it can not know if it is current state or not. That is not

Re: Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109)

Hi, On 13-11-16 10:10, Pavel Machek wrote: On Sat 2016-11-12 09:03:42, Hans de Goede wrote: Hi, On 11-11-16 23:12, Pavel Machek wrote: Hi! Reason #1: Hmm. So userland can read the LED state, and it can get _some_ value back, but it can not know if it is current state or not. That is not

Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109)

On Sat 2016-11-12 09:03:42, Hans de Goede wrote: > Hi, > > On 11-11-16 23:12, Pavel Machek wrote: > >Hi! > > > >Reason #1: > > > Hmm. So userland can read the LED state, and it can get _some_ value > back, but it can not know if it is current state or not. > > That is not correct, the

Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109)

On Sat 2016-11-12 09:03:42, Hans de Goede wrote: > Hi, > > On 11-11-16 23:12, Pavel Machek wrote: > >Hi! > > > >Reason #1: > > > Hmm. So userland can read the LED state, and it can get _some_ value > back, but it can not know if it is current state or not. > > That is not correct, the

Re: PM regression with LED changes in next-20161109

Hi, On 12-11-16 20:14, Jacek Anaszewski wrote: Why a dedicated file? Are we going to mirror brightness here wrt r/w (show/store) behavior ? If not userspace now needs 2 open fds which is not really nice. If we are and we are not going to use poll for something else on brightness itself then

Re: PM regression with LED changes in next-20161109

Hi, On 12-11-16 20:14, Jacek Anaszewski wrote: Why a dedicated file? Are we going to mirror brightness here wrt r/w (show/store) behavior ? If not userspace now needs 2 open fds which is not really nice. If we are and we are not going to use poll for something else on brightness itself then

Re: PM regression with LED changes in next-20161109

Hi, On 11/12/2016 11:33 AM, Hans de Goede wrote: Hi, On 12-11-16 11:24, Jacek Anaszewski wrote: Hi, On 11/11/2016 08:28 PM, Hans de Goede wrote: Hi, On 11-11-16 18:03, Jacek Anaszewski wrote: On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote:

Re: PM regression with LED changes in next-20161109

Hi, On 11/12/2016 11:33 AM, Hans de Goede wrote: Hi, On 12-11-16 11:24, Jacek Anaszewski wrote: Hi, On 11/11/2016 08:28 PM, Hans de Goede wrote: Hi, On 11-11-16 18:03, Jacek Anaszewski wrote: On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote:

Re: PM regression with LED changes in next-20161109

Hi, On 12-11-16 11:24, Jacek Anaszewski wrote: Hi, On 11/11/2016 08:28 PM, Hans de Goede wrote: Hi, On 11-11-16 18:03, Jacek Anaszewski wrote: On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote:

Re: PM regression with LED changes in next-20161109

Hi, On 12-11-16 11:24, Jacek Anaszewski wrote: Hi, On 11/11/2016 08:28 PM, Hans de Goede wrote: Hi, On 11-11-16 18:03, Jacek Anaszewski wrote: On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote:

Re: PM regression with LED changes in next-20161109

Hi, On 11/11/2016 08:28 PM, Hans de Goede wrote: Hi, On 11-11-16 18:03, Jacek Anaszewski wrote: On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote: On Thu 2016-11-10 10:55:37, Tony Lindgren wrote:

Re: PM regression with LED changes in next-20161109

Hi, On 11/11/2016 08:28 PM, Hans de Goede wrote: Hi, On 11-11-16 18:03, Jacek Anaszewski wrote: On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote: On Thu 2016-11-10 10:55:37, Tony Lindgren wrote:

Re: PM regression with LED changes in next-20161109

Hi, On 11-11-16 23:12, Pavel Machek wrote: Hi! Reason #1: Hmm. So userland can read the LED state, and it can get _some_ value back, but it can not know if it is current state or not. That is not correct, the current behavior for eading the brightness atrribute is to always return the

Re: PM regression with LED changes in next-20161109

Hi, On 11-11-16 23:12, Pavel Machek wrote: Hi! Reason #1: Hmm. So userland can read the LED state, and it can get _some_ value back, but it can not know if it is current state or not. That is not correct, the current behavior for eading the brightness atrribute is to always return the

Re: PM regression with LED changes in next-20161109

Hi! Reason #1: > >>Hmm. So userland can read the LED state, and it can get _some_ value > >>back, but it can not know if it is current state or not. > Why a dedicated file? Are we going to mirror brightness here > wrt r/w (show/store) behavior ? If not userspace now needs > 2 open fds which is

Re: PM regression with LED changes in next-20161109

Hi! Reason #1: > >>Hmm. So userland can read the LED state, and it can get _some_ value > >>back, but it can not know if it is current state or not. > Why a dedicated file? Are we going to mirror brightness here > wrt r/w (show/store) behavior ? If not userspace now needs > 2 open fds which is

Re: PM regression with LED changes in next-20161109

Hi! > >Hmm. So userland can read the LED state, and it can get _some_ value > >back, but it can not know if it is current state or not. > > > >I don't think that's a good interface. I see it is from 2008... is > >someone using it? Maybe it is too late for revert. > > I can imagine it being used

Re: PM regression with LED changes in next-20161109

Hi! > >Hmm. So userland can read the LED state, and it can get _some_ value > >back, but it can not know if it is current state or not. > > > >I don't think that's a good interface. I see it is from 2008... is > >someone using it? Maybe it is too late for revert. > > I can imagine it being used

Re: PM regression with LED changes in next-20161109

Hi, On 11-11-16 18:03, Jacek Anaszewski wrote: On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote: On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: * Pavel Machek [161110 09:29]: Hi!

Re: PM regression with LED changes in next-20161109

Hi, On 11-11-16 18:03, Jacek Anaszewski wrote: On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote: On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: * Pavel Machek [161110 09:29]: Hi! Looks like

Re: PM regression with LED changes in next-20161109

On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote: On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: * Pavel Machek [161110 09:29]: Hi! Looks like commit 883d32ce3385 ("leds: core:

Re: PM regression with LED changes in next-20161109

On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote: On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: * Pavel Machek [161110 09:29]: Hi! Looks like commit 883d32ce3385 ("leds: core: Add support for

Re: PM regression with LED changes in next-20161109

On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: > Hi, > > On 11/10/2016 09:29 PM, Pavel Machek wrote: > >On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: > >>* Pavel Machek [161110 09:29]: > >>>Hi! > >>> > >>>Looks like commit 883d32ce3385 ("leds: core: Add support for

Re: PM regression with LED changes in next-20161109

On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: > Hi, > > On 11/10/2016 09:29 PM, Pavel Machek wrote: > >On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: > >>* Pavel Machek [161110 09:29]: > >>>Hi! > >>> > >>>Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing >

Re: PM regression with LED changes in next-20161109

Hi, On 10-11-16 21:48, Pavel Machek wrote: Hi! 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.

Re: PM regression with LED changes in next-20161109

Hi, On 10-11-16 21:48, Pavel Machek wrote: Hi! 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.

Re: PM regression with LED changes in next-20161109

Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote: On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: * Pavel Machek [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

Re: PM regression with LED changes in next-20161109

Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote: On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: * Pavel Machek [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

Re: PM regression with LED changes in next-20161109

Hi! > >>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

Re: PM regression with LED changes in next-20161109

Hi! > >>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

Re: PM regression with LED changes in next-20161109

On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: > * Pavel Machek [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

Re: PM regression with LED changes in next-20161109

On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: > * Pavel Machek [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

Re: PM regression with LED changes in next-20161109

* Pavel Machek [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 > >

Re: PM regression with LED changes in next-20161109

* Pavel Machek [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

Re: PM regression with LED changes in next-20161109

Hi, On 10-11-16 17:29, Pavel Machek 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

Re: PM regression with LED changes in next-20161109

Hi, On 10-11-16 17:29, Pavel Machek 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

Re: PM regression with LED changes in next-20161109

Hi! > >>>The current docs say not about (sw) blinking, but that should be treated > >>>just > >>>like a trigger IMHO. > >> > >>You'r right, we should describe the semantics on reading, but it would > >>have to be as follows: > >> > >>Reading from this file returns LED brightness at given moment,

Re: PM regression with LED changes in next-20161109

Hi! > >>>The current docs say not about (sw) blinking, but that should be treated > >>>just > >>>like a trigger IMHO. > >> > >>You'r right, we should describe the semantics on reading, but it would > >>have to be as follows: > >> > >>Reading from this file returns LED brightness at given moment,

Re: PM regression with LED changes in next-20161109

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

Re: PM regression with LED changes in next-20161109

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

Re: PM regression with LED changes in next-20161109

* 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

Re: PM regression with LED changes in next-20161109

* 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

Re: PM regression with LED changes in next-20161109

Hi, On 11/10/2016 02:04 PM, Hans de Goede wrote: Hi, On 10-11-16 13:56, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:49 AM, Hans de Goede wrote: Hi, On 09-11-16 21:45, Jacek Anaszewski wrote: Hi Tony, On 11/09/2016 08:23 PM, Tony Lindgren wrote: Hi, Looks like commit 883d32ce3385

Re: PM regression with LED changes in next-20161109

Hi, On 11/10/2016 02:04 PM, Hans de Goede wrote: Hi, On 10-11-16 13:56, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:49 AM, Hans de Goede wrote: Hi, On 09-11-16 21:45, Jacek Anaszewski wrote: Hi Tony, On 11/09/2016 08:23 PM, Tony Lindgren wrote: Hi, Looks like commit 883d32ce3385

Re: PM regression with LED changes in next-20161109

Hi, On 10-11-16 13:56, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:49 AM, Hans de Goede wrote: Hi, On 09-11-16 21:45, Jacek Anaszewski wrote: Hi Tony, On 11/09/2016 08:23 PM, Tony Lindgren wrote: Hi, Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing the sysfs

Re: PM regression with LED changes in next-20161109

Hi, On 10-11-16 13:56, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:49 AM, Hans de Goede wrote: Hi, On 09-11-16 21:45, Jacek Anaszewski wrote: Hi Tony, On 11/09/2016 08:23 PM, Tony Lindgren wrote: Hi, Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing the sysfs

Re: PM regression with LED changes in next-20161109

Hi, On 11/10/2016 09:49 AM, Hans de Goede wrote: Hi, On 09-11-16 21:45, Jacek Anaszewski wrote: Hi Tony, On 11/09/2016 08:23 PM, 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

Re: PM regression with LED changes in next-20161109

Hi, On 11/10/2016 09:49 AM, Hans de Goede wrote: Hi, On 09-11-16 21:45, Jacek Anaszewski wrote: Hi Tony, On 11/09/2016 08:23 PM, 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

Re: PM regression with LED changes in next-20161109

Hi, On 09-11-16 21:45, Jacek Anaszewski wrote: Hi Tony, On 11/09/2016 08:23 PM, 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

Re: PM regression with LED changes in next-20161109

Hi, On 09-11-16 21:45, Jacek Anaszewski wrote: Hi Tony, On 11/09/2016 08:23 PM, 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

Re: PM regression with LED changes in next-20161109

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

Re: PM regression with LED changes in next-20161109

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

Re: PM regression with LED changes in next-20161109

Hi Tony, On 11/09/2016 08:23 PM, 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

Re: PM regression with LED changes in next-20161109

Hi Tony, On 11/09/2016 08:23 PM, 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

PM regression with LED changes in next-20161109

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

PM regression with LED changes in next-20161109

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

  1   2   >