On Wed, Aug 24, 2022 at 11:39 AM Jean-Jacques HiblotNo. The TLC5925 driver updates the register asynchronously: the cached value of the register is updated synchronously and then it is transferred over SPI using a workqueue. This way if multiple LED are set in a short time, the changes are coalesced into a single SPI transfer. This is however probably not a must-have feature.
<jjhiblot@xxxxxxxxxxxxxxx> wrote:
On 04/08/2022 23:04, Pavel Machek wrote:...
On Thu 2022-08-04 22:23:00, Jean-Jacques Hiblot wrote:
On 31/07/2022 21:28, Andy Shevchenko wrote:
On Fri, Jul 22, 2022 at 10:14 AM Jean-Jacques Hiblot
<jjhiblot@xxxxxxxxxxxxxxx> wrote:
Let's leave it to the case when it will be needed. So, we can skip this point.sorry for the delay. I tried with the 74x164 gpio driver and it worksIt is certainly preffered solution. If you decide to re-submit theSorry for my slowpokeness, but I just realized that this driver mayIt might work. However it might not be as practical and efficient as the
not be needed. What is the difference to existing gpio-74x164?
dedicated LED driver.
I'll give a try.
driver anyway, please mention that we already have GPIO driver for
compatible chip, and explain why this is superior.
as expected.
The only drawbacks are:
- as-is the 74x164 gpio driver supports only one output-enable gpio.
However in practice I don't think multiple OE GPIOs will ever be used.
- with this approach, every time a LED status is changed the wholeBut isn't it the same as what you do in your driver? To me it looks
register has to be sent on the SPI bus. In other words, changes cannot
be coalesced.
like you send the entire range of the values each time you change one
LED's brightness. I don't see any differences with the GPIO driver.
I don't know if this is enough to make a dedicated TLC5925 driverI don't think you have enough justification for a new driver.
desirable in the kernel.