On 24/08/2022 10:55, Andy Shevchenko wrote:
On Wed, Aug 24, 2022 at 11:39 AM Jean-Jacques Hiblot
<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:
...
Sorry for my slowpokeness, but I just realized that this driver may
not be needed. What is the difference to existing gpio-74x164?
It might work. However it might not be as practical and efficient as the
dedicated LED driver.
I'll give a try.
It is certainly preffered solution. If you decide to re-submit the
driver anyway, please mention that we already have GPIO driver for
compatible chip, and explain why this is superior.
sorry for the delay. I tried with the 74x164 gpio driver and it works
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.
Let's leave it to the case when it will be needed. So, we can skip this point.
- with this approach, every time a LED status is changed the whole
register has to be sent on the SPI bus. In other words, changes cannot
be coalesced.
But isn't it the same as what you do in your driver? To me it looks
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.
No. 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.
I don't know if this is enough to make a dedicated TLC5925 driver
desirable in the kernel.
I don't think you have enough justification for a new driver.
