Driver for adding support for LEDs and mode switch on PC engines APU boards. Can be built as a module or linked into kernel. Upon loading the driver creates four devices. Three led(4) devices: /dev/led/led1 /dev/led/led2 /dev/led/led3 One for the mode switch: /dev/modesw Reading from /dev/modesw will return '1' or '0' depending upon if mode switch is pressed or not.
For compiling on latest -current, we just had to replace the getenv() by kern_getenv().
Created attachment 157102 [details] patch modified as diffs from current (11.0) Tested on APU. Happy LEDs...
Created attachment 178995 [details] Module to support LEDs on both APU1 and APU2 boards. The updated patch has logic to detect if it is running on an APU1 or an APU2 board from PC Engines. It will then add support for all three LEDs and switch on the front of the box.
I've created a phabricator review about this new drivers: https://reviews.freebsd.org/D9876
Created attachment 182445 [details] Updated APU led driver that support APU1, APU2, and APU3 Code in phabricator also updated.
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"
^Triage: It would be lovely to land this driver. The latest attachments needs: - A test (validation) against CURRENT and a rebase if necessary - Test confirmation against APU boards
The code on the review was updated to be compliant on -head (https://reviews.freebsd.org/D9876).
(In reply to Olivier Cochard from comment #8) And it was tested on an APU2 (LEDs and reset switch).
My personal opinion. The gpio controller on APU2 is the standard AMD GPIO controller. With the latest firmware it is advertised via ACPI, so amdgpu driver can attach perfectly well and gpioctl can be used to control the LEDs and query the switch. Of course, that is not convenient at all. But the latest firmware also describes the LEDs and the switch via ACPI. So, we need some glue to parse the ACPI description and attach the standard gpioled and gpiokeys drivers under amdgpu. That would be very similar to what is done on FDT based systems. I think that such approach would be more extensible than hardcoding everything is a platform specific driver.
Created attachment 217302 [details] APU2 DSDT, firmware v4.11.0.6 See the attached DSDT for LEDS and BTNS elements.
(In reply to Andriy Gapon from comment #10) Yes your design idea seems cleaner than the existing code. But: - There is a working patch waiting to be committed since 2014; - I don't know C & drivers coding: I've just adapted & tested the existing old patch, and it accidentally works. So, who will be able to rewrite it (in less than other 6 years)?
(In reply to Olivier Cochard from comment #12) You are right, the perfect is the enemy of the good, of course. I think that the current driver code can be a kmod port. We have many useful kernel drivers in the ports. There is a much lower barrier to entry and more flexibility. And for the end users it's almost as convenient.
Created a review request for the suggested ACPI-based driver: https://reviews.freebsd.org/D9876
(In reply to Andriy Gapon from comment #14) Pardon. The correct link is: https://reviews.freebsd.org/D26311
MARKED AS SPAM