[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1a1017f5-b18f-b952-2504-e4301512c52b@sberdevices.ru>
Date: Thu, 2 Mar 2023 17:00:31 +0300
From: Martin Kurbanov <mmkurbanov@...rdevices.ru>
To: Pavel Machek <pavel@....cz>
CC: Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Lee Jones <lee@...nel.org>,
Andy Shevchenko <andy.shevchenko@...il.com>,
<linux-leds@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <kernel@...rdevices.ru>
Subject: Re: [PATCH v2 2/2] leds: add aw20xx driver
On 2023-03-01 00:24, Pavel Machek wrote:
> Hi!
>
>> +config LEDS_AW200XX
>> + tristate "LED support for Awinic AW20036/AW20054/AW20072"
>> + depends on LEDS_CLASS
>> + depends on I2C
>> + help
>> + This option enables support for the AW20036/AW20054/AW20072 LED driver.
>> + It is a 3x12/6x9/6x12 matrix LED driver programmed via
>> + an I2C interface, up to 36/54/72 LEDs or 12/18/24 RGBs,
>> + 3 pattern controllers for auto breathing or group dimming control.
>
> I'm afraid this should be handled as a display, not as an array of
> individual LEDs.
Hello Pavel,
Thank you for the quick feedback and your detailed thoughts, appreciate
it!
I'm totally agree with you, that matrix LED controllers should be
interpreted as display and it must be controlled as display from
userspace. But actually, AW20036 controller usage status is strongly
dependent from board PCB. In the our internal projects AW20036 controls
LEDs line. Each LED brightness/pattern/etc are managed from userspace
independently. From the current registers specification I can't imagine
that it's possible to develop display driver for that. All controller
features involve LED independent managing, like hardware patterns and
brightness setup. Therefore I suppose for AW20036 controller LED
subsystem is more suitable.
--
Best Regards,
Kurbanov Martin
Powered by blists - more mailing lists