Hello Everyone,
Recently I looked into the onboard LED labels and triggers for 96Boards in Linux kernel. It looked very obvious that there is no standard or recommended way of implementation and every board implements its own way.
This will become cumbersome to maintain userspace support in MRAA library, which we recommend for peripherals access. So I thought of standardizing it across all mainline supported 96Boards.
Below is the format I came up with:
device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: onboard-storage (mmc0 or disk-activity) device-name:green:user3 default-trigger: SD-card (mmc1) device-name:green:user4 default-trigger: none, panic-indicator device-name:yellow:wlan default-trigger: phy0tx device-name:blue:bt default-trigger: hci0-power
Issues:
1. We have MMC and SATA triggers but no UFS trigger AFAIK. So, boards implementing UFS storage will not use LED 2.
2. Currently, we can't specify the order of storage devices. It is preferred to assign "storage0" for onboard memory but it will not be true all the time.
3. Not sure whether "phy0tx" will work with boards with Ethernet interfaces.
4. Modifying the LED labels may break current userspace scripts implemented by the users. But it will favor MRAA library for providing a generic interface to LEDs.
I hope to get feeback on the above proposal here so that we can move forward with it. If we can agree on a common format, we can also discuss to add it as a recommendation in the Specs.
Thanks, Mani
Op 3 sep. 2018, om 17:55 heeft Manivannan Sadhasivam manivannan.sadhasivam@linaro.org het volgende geschreven:
Hello Everyone,
Recently I looked into the onboard LED labels and triggers for 96Boards in Linux kernel. It looked very obvious that there is no standard or recommended way of implementation and every board implements its own way.
The 96boards spec[1] says the following:
"System and User LEDs
The following LEDs shallbe present on the board. The LEDs shallbe of the specified size, color and location. The User LEDs shallbe directly programmable from the SoC.
• WiFi activity LED
• Bluetooth activity LED
• User LEDs x4
Other LEDs and UI interfaces are optional."
This will become cumbersome to maintain userspace support in MRAA library, which we recommend for peripherals access. So I thought of standardizing it across all mainline supported 96Boards.
Below is the format I came up with:
device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: onboard-storage (mmc0 or disk-activity) device-name:green:user3 default-trigger: SD-card (mmc1) device-name:green:user4 default-trigger: none, panic-indicator device-name:yellow:wlan default-trigger: phy0tx device-name:blue:bt default-trigger: hci0-power
That looks OK from me, aside from the bluetooth one not being ‘activity’, but ‘power’.
regards,
Koen
[1] https://www.96boards.org/documentation/Specifications/96Boards-CE-Specificat...
Issues:
- We have MMC and SATA triggers but no UFS trigger AFAIK. So, boards
implementing UFS storage will not use LED 2.
- Currently, we can't specify the order of storage devices. It is preferred to
assign "storage0" for onboard memory but it will not be true all the time.
Not sure whether "phy0tx" will work with boards with Ethernet interfaces.
Modifying the LED labels may break current userspace scripts implemented
by the users. But it will favor MRAA library for providing a generic interface to LEDs.
I hope to get feeback on the above proposal here so that we can move forward with it. If we can agree on a common format, we can also discuss to add it as a recommendation in the Specs.
Thanks, Mani _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Tue, Sep 04, 2018 at 08:14:13AM +0200, Koen Kooi wrote:
Op 3 sep. 2018, om 17:55 heeft Manivannan Sadhasivam manivannan.sadhasivam@linaro.org het volgende geschreven:
Hello Everyone,
Recently I looked into the onboard LED labels and triggers for 96Boards in Linux kernel. It looked very obvious that there is no standard or recommended way of implementation and every board implements its own way.
The 96boards spec[1] says the following:
"System and User LEDs
The following LEDs shallbe present on the board. The LEDs shallbe of the specified size, color and location. The User LEDs shallbe directly programmable from the SoC.
• WiFi activity LED
• Bluetooth activity LED
• User LEDs x4
Other LEDs and UI interfaces are optional."
Hi Koen,
Yes, currently we don't mandate/recommend the User LED configurations but I think we should.
This will become cumbersome to maintain userspace support in MRAA library, which we recommend for peripherals access. So I thought of standardizing it across all mainline supported 96Boards.
Below is the format I came up with:
device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: onboard-storage (mmc0 or disk-activity) device-name:green:user3 default-trigger: SD-card (mmc1) device-name:green:user4 default-trigger: none, panic-indicator device-name:yellow:wlan default-trigger: phy0tx device-name:blue:bt default-trigger: hci0-power
That looks OK from me, aside from the bluetooth one not being ‘activity’, but ‘power’.
There is no activity trigger for Bluetooth in kernel. Only the following triggers:
"bluetooth-power" - Global bluetooth power trigger "hcin-power" where n = 0,1,2... - Per controller power trigger
Since the spec allows only one onboard BT controller, use of "hci0-power" makes sense to me.
Thanks for the feedback.
Regards, Mani
regards,
Koen
[1] https://www.96boards.org/documentation/Specifications/96Boards-CE-Specificat...
Issues:
- We have MMC and SATA triggers but no UFS trigger AFAIK. So, boards
implementing UFS storage will not use LED 2.
- Currently, we can't specify the order of storage devices. It is preferred to
assign "storage0" for onboard memory but it will not be true all the time.
Not sure whether "phy0tx" will work with boards with Ethernet interfaces.
Modifying the LED labels may break current userspace scripts implemented
by the users. But it will favor MRAA library for providing a generic interface to LEDs.
I hope to get feeback on the above proposal here so that we can move forward with it. If we can agree on a common format, we can also discuss to add it as a recommendation in the Specs.
Thanks, Mani _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Op 4 sep. 2018, om 08:20 heeft Manivannan Sadhasivam manivannan.sadhasivam@linaro.org het volgende geschreven:
On Tue, Sep 04, 2018 at 08:14:13AM +0200, Koen Kooi wrote:
Op 3 sep. 2018, om 17:55 heeft Manivannan Sadhasivam manivannan.sadhasivam@linaro.org het volgende geschreven:
Hello Everyone,
Recently I looked into the onboard LED labels and triggers for 96Boards in Linux kernel. It looked very obvious that there is no standard or recommended way of implementation and every board implements its own way.
The 96boards spec[1] says the following:
"System and User LEDs
The following LEDs shallbe present on the board. The LEDs shallbe of the specified size, color and location. The User LEDs shallbe directly programmable from the SoC.
• WiFi activity LED
• Bluetooth activity LED
• User LEDs x4
Other LEDs and UI interfaces are optional."
Hi Koen,
Yes, currently we don't mandate/recommend the User LED configurations but I think we should.
This will become cumbersome to maintain userspace support in MRAA library, which we recommend for peripherals access. So I thought of standardizing it across all mainline supported 96Boards.
Below is the format I came up with:
device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: onboard-storage (mmc0 or disk-activity) device-name:green:user3 default-trigger: SD-card (mmc1) device-name:green:user4 default-trigger: none, panic-indicator device-name:yellow:wlan default-trigger: phy0tx device-name:blue:bt default-trigger: hci0-power
That looks OK from me, aside from the bluetooth one not being ‘activity’, but ‘power’.
There is no activity trigger for Bluetooth in kernel. Only the following triggers:
"bluetooth-power" - Global bluetooth power trigger "hcin-power" where n = 0,1,2... - Per controller power trigger
That means the trigger hisilicon wrote for the original hikey didn’t make it upstream :( Marcel’s comment show that just looking at hci traffic isn’t the way: https://lkml.org/lkml/2016/6/23/17
regards,
Koen
Since the spec allows only one onboard BT controller, use of "hci0-power" makes sense to me.
Thanks for the feedback.
Regards, Mani
regards,
Koen
[1] https://www.96boards.org/documentation/Specifications/96Boards-CE-Specificat...
Issues:
- We have MMC and SATA triggers but no UFS trigger AFAIK. So, boards
implementing UFS storage will not use LED 2.
- Currently, we can't specify the order of storage devices. It is preferred to
assign "storage0" for onboard memory but it will not be true all the time.
Not sure whether "phy0tx" will work with boards with Ethernet interfaces.
Modifying the LED labels may break current userspace scripts implemented
by the users. But it will favor MRAA library for providing a generic interface to LEDs.
I hope to get feeback on the above proposal here so that we can move forward with it. If we can agree on a common format, we can also discuss to add it as a recommendation in the Specs.
Thanks, Mani _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Tue, Sep 04, 2018 at 09:14:57AM +0200, Koen Kooi wrote:
Op 4 sep. 2018, om 08:20 heeft Manivannan Sadhasivam manivannan.sadhasivam@linaro.org het volgende geschreven:
On Tue, Sep 04, 2018 at 08:14:13AM +0200, Koen Kooi wrote:
Op 3 sep. 2018, om 17:55 heeft Manivannan Sadhasivam manivannan.sadhasivam@linaro.org het volgende geschreven:
Hello Everyone,
Recently I looked into the onboard LED labels and triggers for 96Boards in Linux kernel. It looked very obvious that there is no standard or recommended way of implementation and every board implements its own way.
The 96boards spec[1] says the following:
"System and User LEDs
The following LEDs shallbe present on the board. The LEDs shallbe of the specified size, color and location. The User LEDs shallbe directly programmable from the SoC.
• WiFi activity LED
• Bluetooth activity LED
• User LEDs x4
Other LEDs and UI interfaces are optional."
Hi Koen,
Yes, currently we don't mandate/recommend the User LED configurations but I think we should.
This will become cumbersome to maintain userspace support in MRAA library, which we recommend for peripherals access. So I thought of standardizing it across all mainline supported 96Boards.
Below is the format I came up with:
device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: onboard-storage (mmc0 or disk-activity) device-name:green:user3 default-trigger: SD-card (mmc1) device-name:green:user4 default-trigger: none, panic-indicator device-name:yellow:wlan default-trigger: phy0tx device-name:blue:bt default-trigger: hci0-power
That looks OK from me, aside from the bluetooth one not being ‘activity’, but ‘power’.
There is no activity trigger for Bluetooth in kernel. Only the following triggers:
"bluetooth-power" - Global bluetooth power trigger "hcin-power" where n = 0,1,2... - Per controller power trigger
That means the trigger hisilicon wrote for the original hikey didn’t make it upstream :( Marcel’s comment show that just looking at hci traffic isn’t the way: https://lkml.org/lkml/2016/6/23/17
Yes, you are right. I had a quick chat with Loic on this and he said that for activity trigger we need to choose either hci traffic between the host and the controller or air traffic between controller and peer. While the later is more tough to implement.
Anyway, we can choose "hci0-power" for now and later if someone (even we) implement an activity trigger, it can be replaced.
Thanks, Mani
regards,
Koen
Since the spec allows only one onboard BT controller, use of "hci0-power" makes sense to me.
Thanks for the feedback.
Regards, Mani
regards,
Koen
[1] https://www.96boards.org/documentation/Specifications/96Boards-CE-Specificat...
Issues:
- We have MMC and SATA triggers but no UFS trigger AFAIK. So, boards
implementing UFS storage will not use LED 2.
- Currently, we can't specify the order of storage devices. It is preferred to
assign "storage0" for onboard memory but it will not be true all the time.
Not sure whether "phy0tx" will work with boards with Ethernet interfaces.
Modifying the LED labels may break current userspace scripts implemented
by the users. But it will favor MRAA library for providing a generic interface to LEDs.
I hope to get feeback on the above proposal here so that we can move forward with it. If we can agree on a common format, we can also discuss to add it as a recommendation in the Specs.
Thanks, Mani _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Mon, Sep 3, 2018 at 5:55 PM Manivannan Sadhasivam manivannan.sadhasivam@linaro.org wrote:
- We have MMC and SATA triggers but no UFS trigger AFAIK. So, boards
implementing UFS storage will not use LED 2.
The generic disk activity trigger is usually registered. I guess this is because UFS lives in SCSI and SCSI does not call ledtrig_disk_activity() when stuff happens on a SCSI device.
ATA and IDE does... I think it's just a matter of patching something inside drivers/scsi/* and it should work fine with UFS too. It should have been done ages ago, just noone did it.
I would do it if I had a SCSI or UFS system running but I don't.
Yours, Linus Walleij
Hi Linus,
On Thu, Sep 06, 2018 at 12:11:53PM +0200, Linus Walleij wrote:
On Mon, Sep 3, 2018 at 5:55 PM Manivannan Sadhasivam manivannan.sadhasivam@linaro.org wrote:
- We have MMC and SATA triggers but no UFS trigger AFAIK. So, boards
implementing UFS storage will not use LED 2.
The generic disk activity trigger is usually registered. I guess this is because UFS lives in SCSI and SCSI does not call ledtrig_disk_activity() when stuff happens on a SCSI device.
Yes.
ATA and IDE does... I think it's just a matter of patching something inside drivers/scsi/* and it should work fine with UFS too. It should have been done ages ago, just noone did it.
I would do it if I had a SCSI or UFS system running but I don't.
Makes sense! Will look into it along with this patchseries.
Thanks, Mani
Yours, Linus Walleij
-
Koen Kooi -
Linus Walleij -
Manivannan Sadhasivam