Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210511204834.2675271-1-dougdev334@gmail.com>
 <20210511204834.2675271-3-dougdev334@gmail.com> <20210513022036.GA890569@robh.at.kernel.org>
 <CABa6EMYdY9WBN0+edgcEFc0uiBmWUDert7nXCN+FWeRMG=0S6A@mail.gmail.com> <20210516183135.GA26985@duo.ucw.cz>
In-Reply-To: <20210516183135.GA26985@duo.ucw.cz>
From:   Doug Zobel <dougdev334@gmail.com>
Date:   Mon, 17 May 2021 15:07:41 -0500
Message-ID: <CABa6EMaEFLKrrhnH2+3wEEGJkWH7fQQpQrKRh=KHR6KfSgTsnA@mail.gmail.com>
Subject: Re: [PATCH 2/2] dt: bindings: lp55xx: Add predefined LED pattern
To:     Pavel Machek <pavel@ucw.cz>
Cc:     Rob Herring <robh@kernel.org>,
        Jacek Anaszewski <jacek.anaszewski@gmail.com>,
        linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> Take a look at the pattern trigger. That's the way to change patterns
> at runtime, no need for firmware loading.

Thanks for the pointer.  That looks like it could work.  I would need
to add support for the lp5562 to run the patterns in hardware.  The
only problem I see is in synchronizing the 3 color channels.  Since
the pattern triggers are associated with each individual channel, I
don't see a clean way to run a multi-chanel (RGB) pattern and keep it
in sync.  I was thinking I could restart all 3 channels' programs
anytime a channel program is changed.  This would assure they start in
sync.  However that would cause glitches in the patterns if they are
being used as 3 independent (non-RGB) patterns.

> I may even have compiler from that interface to the bytecode lp55xx
> uses. Some assembly will be required. Doing so with the RGB LED will
> be even more fun.

If you have some previous work on this, I could use it.  Otherwise
I'll just write my own bytecode generator.  As far as I know the
lp5562 is the only lp55xx controller which supports on chip
programming.  So I would add the support in the lp5562 driver.

> We'll want to deprecate the firmware loading interface at some point.

If I add support for running the pattern triggers in lp5562 hardware,
then this will now be the 3rd method (firmware &
lp5562_run_predef_led_pattern() are the other two) for loading custom
patterns onto the chip.  Will this be a problem?

-Doug