* H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [160928 08:29]: > > > Am 28.09.2016 um 17:12 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > > > > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [160927 23:50]: > >> Hi, > >> > >>> Am 28.09.2016 um 05:37 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > >>> > >>> * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [160927 13:11]: > >>>>> Am 27.09.2016 um 21:49 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > >>>>> How about this for defaults: > >>>>> > >>>>> - heartbeat for led3 > >>>>> - cpu0 for led4 > >>>>> - cpu1 for led5 > >>>> > >>>> Good idea. Will try. > >>>> > >>>> What I don't exactly know is if these gpios based on an I2C-expander > >>>> can handle cpu activity triggers or if they are locked up if this i2c > >>>> processing triggers another cpu activity... > >>> > >>> Oh right, if the GPIOs are on the i2c bus > >> > >> yes, they are all gpio9 which is the tca6424 on i2c5. > >> > >>> it's probably not a good > >>> idea :) Or at least will be inaccurate if the bus can sleep. > >> > >> I have tested a little by writing to /sys/class/leds/.../trigger. > >> > >> If I make one LED trigger by "cpu0" it is always on and if I make > >> a second one triggered by "cpu1" the heartbeat becomes irregular. > >> > >> So indeed this does not work. > > > > So should we just leave the default trigger unpopulated then? > > It is a matter of taste and something not easy to decide... > > And everything can be changed from user-space by some script > running during the boot process to a more meaningful setting. > > So the initial setting doesn't matter really much. > > Having some of the LEDs as heartbeat gives an (additional) > feedback that the kernel has booted. > > We could even take led1, led3 and led5 as heartbeat and the other > two as default-on. Would give a nice pattern showing that the LEDs > are not broken... > > So let me know how you would like to have it and I add it to a PATCH v2. Up to you for the blinking, I'm fine with the original version too unless you feel like changing it. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
