* Sebastian Reichel [off-list ref] [160329 07:53]:

Hi,

On Tue, Mar 29, 2016 at 12:51:28PM +0200, Pavel Machek wrote:

quoted

For 1-3 in the series, Acked-by: Pavel Machek [off-list ref]

quoted

Like the Nokia N900, the N950 has leds to show
the state of sys_clkreq and sys_off_mode pins.

A detailed description for the LEDs and
OMAP's sleep states can be found in Tony's
commit for the Nokia N900:

c1be2032f66df9e1238bd5bc4ca666de88a62abc

I must say I've seen it on N900, and yes, it is useful, but no, I
don't think this is right.

This is not a LED. This is a interface that changes meaning of two
other LEDs. I guess it should go to debugfs somewhere.

Eh that sounds like a GPIO LED to me :) And it already has a
/sys/class/leds/debug interface.

The two LEDs this GPIO controls are hardwired to sys_clkreq and
sys_off_mode pins that are the control signals between the SoC
and PMIC.

In theory you could steal the sys_clkreq and sys_off_mode pins
from the PMIC at the cost of breaking PM. But I doubt anybody
wants to do that considering it's a battery operated device.

I don't think we should diverge N900 and N950 userspace
APIs in this regard.

Actually the correct way would be a custom trigger
for the leds IMHO. I don't know if the led framework
supports per led custom triggers, though.

Sure, there are something like 10 triggers already. And
you can already change them using:

echo none > /sys/class/leds/debug::sleep/trigger

That still does not change the fact that the LEDs trigger
based on the state of sys_clkreq and sys_off_mode.

Maybe I'm not following what you guys are trying to achieve
here though :) If so, please let me know.

Regards,

Tony


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html