From: Hans de Goede <hdegoede@redhat.com> To: Jacek Anaszewski <j.anaszewski@samsung.com>, Jacek Anaszewski <jacek.anaszewski@gmail.com>, Pavel Machek <pavel@ucw.cz> Cc: Tony Lindgren <tony@atomide.com>, linux-leds@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Darren Hart <dvhart@infradead.org> Subject: Re: PM regression with LED changes in next-20161109 Date: Tue, 15 Nov 2016 11:09:24 +0100 [thread overview] Message-ID: <92b05254-fbb9-c5ed-b0b9-94a1bea872b1@redhat.com> (raw) In-Reply-To: <6d88b2a7-a506-89bf-fc76-af707ed7a00f@samsung.com> Hi, On 15-11-16 11:01, Jacek Anaszewski wrote: > Hi, > > On 11/14/2016 01:51 PM, Hans de Goede wrote: <snip> >> 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 calls dropped, is here: >> >> https://patchwork.kernel.org/patch/9423093/ > > Right I've had an impression that I've already seen something > different than "first" v4. > > Regarding the patch - adding led_notify_brightness_change() to > brightness_store() can have similar power consumption related > implications if brightness is set frequently via sysfs. That means that userspace is waking up frequently to write the sysfs file, so in that case userspace is already draining a lot of energy, so I don't think that is something we need to worry about. > I'm leaning > towards adding a new brightness file similar to user_brightness > discussed in this thread. > > It would cover shortcomings and read/write inconsistencies that > brightness file currently has, but without breaking existing users. > > I'd not however go for "user_brightness" name due to the possible > brightness adjustments made autonomously by firmware. I'm afraid > that devising a meaningful name for the new file will be hard, > so the simplest would be just brighntess2. Dedicated section > in leds-class.txt should be devoted to it. Ok, let me quote myself from another part of this thread: We've 2 sorts of brightness really: 1) transient brightness, aka current brightness, when blinking or triggers are used this will switch many times a second between off and some on level. 2) non-transient brightness, for non blinking leds this is the actual brightness, for blinking leds this is the brightness level used when the led is on. Now we want to have a sysfs attribute reflecting 2, so that userspace can poll on that, both for my use-case as well as so that userspace process a can detect changes made by writing to the brightness file by process b. So maybe we need to simply call the new attribute non_transient_brightness instead of user_brightness? non_transient_brightness certainly seems like a better name then brightness2 ? Regards, Hans
WARNING: multiple messages have this Message-ID (diff)
From: hdegoede@redhat.com (Hans de Goede) To: linux-arm-kernel@lists.infradead.org Subject: PM regression with LED changes in next-20161109 Date: Tue, 15 Nov 2016 11:09:24 +0100 [thread overview] Message-ID: <92b05254-fbb9-c5ed-b0b9-94a1bea872b1@redhat.com> (raw) In-Reply-To: <6d88b2a7-a506-89bf-fc76-af707ed7a00f@samsung.com> Hi, On 15-11-16 11:01, Jacek Anaszewski wrote: > Hi, > > On 11/14/2016 01:51 PM, Hans de Goede wrote: <snip> >> 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 calls dropped, is here: >> >> https://patchwork.kernel.org/patch/9423093/ > > Right I've had an impression that I've already seen something > different than "first" v4. > > Regarding the patch - adding led_notify_brightness_change() to > brightness_store() can have similar power consumption related > implications if brightness is set frequently via sysfs. That means that userspace is waking up frequently to write the sysfs file, so in that case userspace is already draining a lot of energy, so I don't think that is something we need to worry about. > I'm leaning > towards adding a new brightness file similar to user_brightness > discussed in this thread. > > It would cover shortcomings and read/write inconsistencies that > brightness file currently has, but without breaking existing users. > > I'd not however go for "user_brightness" name due to the possible > brightness adjustments made autonomously by firmware. I'm afraid > that devising a meaningful name for the new file will be hard, > so the simplest would be just brighntess2. Dedicated section > in leds-class.txt should be devoted to it. Ok, let me quote myself from another part of this thread: We've 2 sorts of brightness really: 1) transient brightness, aka current brightness, when blinking or triggers are used this will switch many times a second between off and some on level. 2) non-transient brightness, for non blinking leds this is the actual brightness, for blinking leds this is the brightness level used when the led is on. Now we want to have a sysfs attribute reflecting 2, so that userspace can poll on that, both for my use-case as well as so that userspace process a can detect changes made by writing to the brightness file by process b. So maybe we need to simply call the new attribute non_transient_brightness instead of user_brightness? non_transient_brightness certainly seems like a better name then brightness2 ? Regards, Hans
next prev parent reply other threads:[~2016-11-15 10:09 UTC|newest] Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-11-09 19:23 PM regression with LED changes in next-20161109 Tony Lindgren 2016-11-09 19:23 ` Tony Lindgren 2016-11-09 20:45 ` Jacek Anaszewski 2016-11-09 20:45 ` Jacek Anaszewski 2016-11-10 8:49 ` Hans de Goede 2016-11-10 8:49 ` Hans de Goede 2016-11-10 12:56 ` Jacek Anaszewski 2016-11-10 12:56 ` Jacek Anaszewski 2016-11-10 13:04 ` Hans de Goede 2016-11-10 13:04 ` Hans de Goede 2016-11-10 13:55 ` Jacek Anaszewski 2016-11-10 13:55 ` Jacek Anaszewski 2016-11-10 16:36 ` Pavel Machek 2016-11-10 16:36 ` Pavel Machek 2016-11-10 16:29 ` Pavel Machek 2016-11-10 16:29 ` Pavel Machek 2016-11-10 16:44 ` Hans de Goede 2016-11-10 16:44 ` Hans de Goede 2016-11-10 20:48 ` Pavel Machek 2016-11-10 20:48 ` Pavel Machek 2016-11-11 8:25 ` Hans de Goede 2016-11-11 8:25 ` Hans de Goede 2016-11-10 17:55 ` Tony Lindgren 2016-11-10 17:55 ` Tony Lindgren 2016-11-10 20:29 ` Pavel Machek 2016-11-10 20:29 ` Pavel Machek 2016-11-10 21:34 ` Jacek Anaszewski 2016-11-10 21:34 ` Jacek Anaszewski 2016-11-11 12:01 ` Pavel Machek 2016-11-11 12:01 ` Pavel Machek 2016-11-11 17:03 ` Jacek Anaszewski 2016-11-11 17:03 ` Jacek Anaszewski 2016-11-11 19:28 ` Hans de Goede 2016-11-11 19:28 ` Hans de Goede 2016-11-11 22:12 ` Pavel Machek 2016-11-11 22:12 ` Pavel Machek 2016-11-12 8:03 ` Hans de Goede 2016-11-12 8:03 ` Hans de Goede 2016-11-13 9:10 ` Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109) Pavel Machek 2016-11-13 9:10 ` Pavel Machek 2016-11-13 9:44 ` Hans de Goede 2016-11-13 9:44 ` Hans de Goede 2016-11-13 20:45 ` Pavel Machek 2016-11-13 20:45 ` Pavel Machek 2016-11-12 10:24 ` PM regression with LED changes in next-20161109 Jacek Anaszewski 2016-11-12 10:24 ` Jacek Anaszewski 2016-11-12 10:33 ` Hans de Goede 2016-11-12 10:33 ` Hans de Goede 2016-11-12 10:33 ` Hans de Goede 2016-11-12 19:14 ` Jacek Anaszewski 2016-11-12 19:14 ` Jacek Anaszewski 2016-11-12 21:14 ` Hans de Goede 2016-11-12 21:14 ` Hans de Goede 2016-11-13 11:44 ` Jacek Anaszewski 2016-11-13 11:44 ` Jacek Anaszewski 2016-11-13 13:52 ` Hans de Goede 2016-11-13 13:52 ` Hans de Goede 2016-11-14 9:12 ` Jacek Anaszewski 2016-11-14 9:12 ` Jacek Anaszewski 2016-11-14 9:12 ` Jacek Anaszewski 2016-11-14 12:51 ` Hans de Goede 2016-11-14 12:51 ` Hans de Goede 2016-11-15 10:01 ` Jacek Anaszewski 2016-11-15 10:01 ` Jacek Anaszewski 2016-11-15 10:09 ` Hans de Goede [this message] 2016-11-15 10:09 ` Hans de Goede 2016-11-15 10:31 ` LEDs that change brightness "itself" -- that's a trigger. " Pavel Machek 2016-11-15 10:31 ` Pavel Machek 2016-11-15 10:58 ` Jacek Anaszewski 2016-11-15 10:58 ` Jacek Anaszewski 2016-11-15 11:11 ` Pavel Machek 2016-11-15 11:11 ` Pavel Machek 2016-11-15 11:21 ` Hans de Goede 2016-11-15 11:21 ` Hans de Goede 2016-11-15 11:48 ` Pavel Machek 2016-11-15 11:48 ` Pavel Machek 2016-11-15 12:06 ` Hans de Goede 2016-11-15 12:06 ` Hans de Goede 2016-11-15 12:11 ` Pavel Machek 2016-11-15 12:11 ` Pavel Machek 2016-11-15 13:28 ` Jacek Anaszewski 2016-11-15 13:28 ` Jacek Anaszewski 2016-11-15 13:48 ` Hans de Goede 2016-11-15 13:48 ` Hans de Goede 2016-11-15 14:04 ` Jacek Anaszewski 2016-11-15 14:04 ` Jacek Anaszewski 2016-11-15 14:30 ` Hans de Goede 2016-11-15 14:30 ` Hans de Goede 2016-11-15 14:41 ` Jacek Anaszewski 2016-11-15 14:41 ` Jacek Anaszewski 2016-11-17 22:12 ` Hans de Goede 2016-11-17 22:12 ` Hans de Goede 2016-11-15 11:17 ` Hans de Goede 2016-11-15 11:17 ` Hans de Goede 2016-11-14 8:31 ` Pavel Machek 2016-11-14 8:31 ` Pavel Machek 2016-11-11 22:06 ` Pavel Machek 2016-11-11 22:06 ` Pavel Machek 2016-11-10 8:34 ` Hans de Goede 2016-11-10 8:34 ` Hans de Goede 2016-11-10 15:11 ` Tony Lindgren 2016-11-10 15:11 ` Tony Lindgren
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=92b05254-fbb9-c5ed-b0b9-94a1bea872b1@redhat.com \ --to=hdegoede@redhat.com \ --cc=dvhart@infradead.org \ --cc=j.anaszewski@samsung.com \ --cc=jacek.anaszewski@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-leds@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=pavel@ucw.cz \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.