mirror of
https://github.com/openwrt/openwrt.git
synced 2026-10-25 16:53:49 +04:00
André Valentin
ea62d98e7d
The front panel of the NBG7815 carries nine RGB LEDs, driven by three TI LP5569 controllers on the first I2C bus. The stock firmware keeps GPIO 60 high to enable the LED board. The third controller sits at 0x40, where the stock firmware pokes two registers directly instead of binding a driver, and the board schematics call it an LP5009. It answers to the lp5569 register layout though: a write to the pwm registers at 0x16 lights the LEDs, while the lp50xx driver only ever got -EIO. Verified on the device by reading back the registers and by the LEDs actually turning on. Placement and colours were measured with a camera pointed at the front bar, one frame per lit LED against a dark frame. LED1 to LED6 walk through the bar monotonically, so the two controllers form one continuous chain: 0x32 ascending, 0x35 descending, which is also the channel order the stock zled_ctrl script uses. Red, green and blue each come out as the dominant channel on all three controllers. The three groups of the controller at 0x40 light the same spot near the middle of the bar instead, each with about twice the output of a bar segment, so they feed one brighter element together rather than three segments of their own. Channel numbers are per controller. Getting that wrong is quiet but destructive: lp55xx_multicolor_brightness() adds the number to the pwm register base without checking it against the channel count, so the writes land in the current registers of other channels instead. Add the controller nodes with the channel mapping and the LED currents of the stock firmware, the gpio-hog for the LED board enable, and set LED7 to white through board.d. That is the brighter element in the middle rather than one end of the bar, and it is the one the stock firmware keeps driving in every state through its two register writes to 0x40. The same LED is wired to the led-running and led-upgrade aliases, so diag.sh turns it on once the system is up and blinks it while a sysupgrade runs. Measured with a camera at 30 fps: 36 cycles of 200 ms on and 200 ms off for the duration of the flash. led-boot and led-failsafe are deliberately absent. Both states are set from preinit, before the i2c driver for the controller is loaded, so the LED does not exist yet and led_set_attr() silently skips it - confirmed by recording a boot, where the LED stays dark and then comes on in one step. The aliases need a "label" on the multi-led node: get_dt_led() looks for label, then chan-name, and otherwise composes a name from color and function, which would be "rgb:" here. The lp55xx driver only reads "label" from the controller node, so it does not affect the class device name. Signed-off-by: André Valentin <avalentin@marcant.net>