* Sebastian Reichel <sre@xxxxxxxxxx> [160329 07:53]: > Hi, > > On Tue, Mar 29, 2016 at 12:51:28PM +0200, Pavel Machek wrote: > > For 1-3 in the series, Acked-by: Pavel Machek <pavel@xxxxxx> > > > > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
