Hi!

Introduce the KTD2061/58/59/60 RGB LEDs driver. The difference in these
parts are the address number on the I2C bus the device is listen on.

All KT20xx device could control up to 12 LEDs. The chip can be operated
in two variants.

Variant 1:
The device has the ability to group LED outputs into two banks so that
the two LED banks can be controlled with the same color. This could not
be done via the LEDs 'sysfs' entry because of the limitation on the color
register count. The color of the two banks can be configured via device
'sysfs' entry for all LEDs at once [current_color0|current_color1].
Which color the LED is to be used can be set via the 'sysfs' of the
individual LEDs via the 'multi_intensity' file. Valid values for the
colors (RGB) are 0 | 1. The value 0 selects the color register 0 and the
value 1 selects the color register 1.

Variant 2:
The device can also set the LED color independently. Since the chip only
has two color registers, but we want to control the 12 LEDs
independently via the 'led-class-multicolour' sysfs entry,
the full RGB color depth cannot be used. Due to this limitation, only 7
colors and the color black (off) can be set. To use this mode the color
registers must be preset via the device tree or the device 'sysfs'. The
color registers 0 must be preset with 0x00 (Red=0x00 Green=0x00 Blue=0x00).
The color register1 should be preset all with the same value. This value
depends on which light intensity is to be used in the setup.

Summary: some crazy hardware.

+static ssize_t current_color0_store(struct device *dev,
+		struct device_attribute *a,
+		const char *buf, size_t size)
+{

And now we have custom interface. Undocumented.

That is not acceptable, sorry.

Find a way to squeeze it into current RGB framework, perhaps with
reduced feature set.

AFAICT you could either pretend it is 2-LED driver with full 8bit RGB
on each, or you could pretend it is 12-LED driver with 1bit
RGB. Select one and implement that.

Best regards,
									Pavel
-- 
http://www.livejournal.com/~pavelmachek