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 does.
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 you
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, implemente
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 bright
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. D
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 does.
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 the
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 place
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
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 acci
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
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 twice,
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 should
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 w
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 call
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 r
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 behavior
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 (
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:
>
>
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)
>
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 function)
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
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
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 cur
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 w
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:
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:
O
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:
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 curre
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 n
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 i
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 c
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
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
> >>>
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
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 ba
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 t
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 test
* 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
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
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,
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 fo
* 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
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 ("leds
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 brightn
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 me.
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 c
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
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
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
50 matches
Mail list logo