On 9/20/19 10:41 AM, Dan Murphy wrote: > Hello > > Per request I removed the ops structure. But there is a potential need for some > device drivers to have a call back that sets the intesity of the LED color > without modifying the hardware register. The hardware registers are only updated > when the brightness_set<op> is called. The need arises with the LP50xx chip > series where the chip has 2 control knobs to modify the output current to the > LED. In most cases drivers only have a single brightness register for a given > iOUT pin. But the LP50xx has a brightness register that controls cluster > brightness and individual registers to control the monochrome LED intensity. > > The set_color_brightness call back has been simplified in the LP50xx device > driver so that it can cache the LED intensity in it's stack for a specific color > as opposed to having to call back into the MC FW for the current intensity which > made the driver complex. "FW" historically means either firmware or firewire. Please spell out framework in the future. > Once the set_brightness<op> is called the driver can set the brightness and then > set the LED intensity registers if the driver has that ability. > > Dan > > Dan Murphy (9): > leds: multicolor: Add sysfs interface definition > documention: leds: Add multicolor class documentation > dt: bindings: Add multicolor class dt bindings documention > dt-bindings: leds: Add multicolor ID to the color ID list > leds: Add multicolor ID to the color ID list > leds: multicolor: Introduce a multicolor class definition > dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers > leds: lp50xx: Add the LP50XX family of the RGB LED driver > leds: Update the lp55xx to use the multi color framework Thanks. -- ~Randy